#crawl_best-practices
wanton sageBOT
👋 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/1435013456771416155
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
gleaming minnow
Hello, when making the update to the subscription you specify whether to calculate prorations or not and when to charge them. The proration_behavior param is the one that controls this and it defaults to create_prorations which means prorations are calculated but the credit/debit from them is applied to the next invoice when the subscription cycles. More detail on prorations in this doc:
https://docs.stripe.com/billing/subscriptions/prorations
muted nimbus
Here are my business rules
When adding a user mid-cycle:
-They should pay for that extra seat (prorated for the rest of the period).
When removing a user mid-cycle:
-No refunds / credits.
-They’ve already paid for that seat for this period.
-If they re-add someone into that empty seat, we must not charge again for the same period.
-Same logic for monthly, yearly, quarterly… whatever.
So from my understanding is this correct if we do this ? or there is a better way
✅ On increase: update Stripe quantity immediately with create_prorations
✅ On decrease: update our DB immediately (membership removal), but we do not touch Stripe until the next cycle. At renewal (via webhook), set quantity = actual member count with proration_behavior: 'none'.
tldr, is the webhook invoice paid billing_reason="subscription_cycle" success the best timing for us to do this
or we should decrease the quantity before this or after this
@gleaming minnow
gleaming minnow
On an increase if you want to bill immediately you will want to pass proration_behavior: 'always_invoice'. You can also use our pending updates functionality if you want to delay the actual update until after this amount has successfully been paid.
Ah I may have inserted that "immediately" myself. If you don't want to charge the prorated amount until the end of the cycle then create_prorations makes sesne
And yes that event is a good one to listen to for the downgrade as your described
muted nimbus
yes for sure, we already have a mechanism to validate if the payment went through before actually giving the seat
we do want the proration but ONLY for INCREASE
but decrease is only actually done at the end of the cycle
should we do this day-1 the billing invoice paid ? or after the billing invoice paid ?
or there is a better practice for this ?
gleaming minnow
That makes sense as a way to downgrade at the end of the cycle with Stripe. You can make this update whenever makes more sense for your integration. As long as your provisioning logic knows the proper place to look as a source of truth for their current seat count either can work.
If you are making the update call itself at the end of the month, a potential improvement there is passing proration_date so that the update timestamp lines up exactly with when the cycle updates.
Stripe also has subscription schedules which can be used for downgrades like this.
muted nimbus
oh I see ok
what does stripe or you would recommend us, on what best to do ?
do the update call ourself, with the date ? at then end of the cycle ?
or schedule it ?
I think with the scheduling this is a bit more complete if user add and remove back and forth
doing the update call, after receiving the paid, make more sense imo
gleaming minnow
We don't have an official recommendation here, I've seen users do something close to both of those successfully. So it is more a matter of which makes the most sense for your specific situation. Maybe a good thing to do would be play around with all of these in test mode to get a better feel for them?
This server can help explain these behaviors and how they work but only you can decide what makses the most sense for your integration.
wanton sageBOT