#ironbeard_best-practices

1 messages · Page 1 of 1 (latest)

normal nymphBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1451581171195707576

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

ivory mountain
#

Hi there, looking into this now

#

Can you provide a few more details about your use case? Specifically, what do you want to happen to the billing cycle anchor? And is there a specific reason you do not want to use prorations?

supple dove
#

thanks 🙂

I've been struggling to figure this situation out for awhile, and I think this is finally the answer.

Assuming someone subscribes to newsletter+data on Jan 1st, and then upgrades the data on July 1st:

  • doing billing_cycle_anchor=now and proration_behavior=always_invoice they end up paying for 6months more newsletter instead of just the extra data.
  • doing the kind of default proration behavior, if they upgrade on Dec 31st 11pm, then they only pay for 1 hour of the more expensive plan, and they can download the data and unsubscribe
  • tried doing two separate Subscription objects, but that made checkout difficult (having multiple payment intents, etc)
#

Basically, I think the best answer is "If someone buys newsletter ($100) + simple data access ($500) on Jan 1st (total $600) and then on July 1st they decide they want newsletter ($100) + complex data access ($1000, for a total of $1,100), charge them such that they ultimately paid what they would have paid on Jan 1st if they originally bought complex data access" aka charge them $1,100 - $600 on July 1st.

Keep the billing cycle the same. Then the next Jan 1st their subscription should be "newsletter + complex data access"

ivory mountain
#

Okay, trying to digest all of this haha. And are there any differences in pricing intervals (monthly, annual, etc)?

supple dove
#

haha yeah sorry i understand

#

everything is annual

ivory mountain
#

Huh, it's a unique situation, my gut feeling is that you may need to handle a proration calculation on your own since the default proration behavior doesn't work for this use case. But let me keep digging

supple dove
#

I don't mind handling the proration calculation on my end, since it should generally be pretty simple. It is an odd situtation, I think the crux of it is that one of the products is a "pay for access" thing and we have to prevent people from just accessing, downloading, and cancelling without paying the full amount.

#

With prorations, my understanding is that there's no way to keep the billing cycle anchor the same but also require an upfront payment that isn't calculated based on "time remaining":

  • If billing_cycle_anchor=now, then if they upgrade a newsletter+data subscription that was originally "cancel at period end," they'd be paying for extra newsletter.
  • If we keep the billing cycle, then the proration is calculated as time remaining (e.g., if they upgrade Dec 31st 11pm, they only pay for one hour of the subscription, which is what we want to avoid).
ivory mountain
#

So can you use billing_cycle_anchor=now and handle the calculation for the extra newsletter? Or am I missing something?

supple dove
#

Well, I dont want to to use billing_cycle_anchor=now bc of the following:

  • subscriber buys both on Jan 1st 2025 and immediately sets "cancel at period end" to true. They just want both products for one year
  • on July 1st 2025, they realize they need the extended data, but they still want to cancel at the period end.
  • If I do billing_cycle_anchor=now, then their cycle extends to July 1st 2026 and they are immediately asked to pay the cost of the newsletter from Jan1 2026 to July 1 2026
normal nymphBOT
supple dove
#

👋 hey toby

oblique zephyr
#

Hello 👋 working on catching up on the discussion so far.

supple dove
#

❤️ no worries

oblique zephyr
#

Let's start by circling back to the original question. You can set the subscription field when creating an Invoice to associate the two objects. Offhand, I don't think this changes the latest_invoice field on the Subscription, but would need to test to confirm that.

#

Yeah, that doesn't affect the latest_invoice of the Subscription object.

supple dove
#

ugh sorry, I was afk for a second

#

Well, at the moment my check for providing access is if their Subscription has an active status, so I suppose what would be important is that I find a way to remove access if someone does this upgrade path and doesn't pay

#

and when I list invoices for a customer's account page, I just list all invoices associated with the customer, so I suppose it's not crucial that the one-time invoice is associated with a subscription

oblique zephyr
#

I think the problem will be that you can't force the Subscription to go to a non-active state, unless you start a trial period or cancel it.

supple dove
#

Is provisioning access based on the status of the latest invoice a bad idea?

oblique zephyr
#

Not if it works for your use case

#

Checking latest_invoice for that may not be the best if you're issuing one-off Invoices as well, but if you're listing Invoices explicitly then I think that could be a stable approach.

supple dove
#

I'm mirroring a lot of Invoice data in my own db via webhooks, so it should be easy enough to provision access that way

#

...although this would be a mess if I generate the one-off invoice during the checkout process (GET /checkout/review/) and then they change their mind 🙄

#

But I think I have my answer: I could create a new Invoice, with an InvoiceItem based on shopping_cart_total - subscription.latest_invoice.amount_due. I suppose I have to finalize that invoice in order to get a PI to pass to the PE in the front end?

oblique zephyr
#

Correct

supple dove
#

But if i were to just update the subscription (using some combo of billing_cycle_anchor and proration_behavior, then the associated Invoice creation, finalization, and PI creation would all be handled for me, right?

oblique zephyr
#

That is correct

supple dove
#

Thanks, I think I just need to get my hands dirty and compare the different approaches once they're coded. Have a great day 🙂