#inviso-schedule-payment
whole mountainBOT
Hello! We'll be with you shortly. 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.
- trueinviso-prorations, 1 day ago, 40 messages
- trueinviso-invoice-retry-and-draft-finalization, 2 days ago, 36 messages
wary belfry
Hi 👋
The end of the billing cycle is when we invoice the customer. What is the behavior you are trying to achieve?
rapid orchid
for some other types of subscription changes I have to manually charge because I have to manually do some proration changes and credit reimbursements that Stripe can't do on its own. So I either need to prevent Stripe from charging, or somehow figure out in the webhook that this change is happening due to the billing cycle changing.
So for example I do this on other upgrades, some plans charge immediately, while the pro plan doesn't charge immediately, maintains the billing cycle end date, and then in the subscription updated webhook I do the charge manually.
I have a specific scenario where a user is on a hold plan, and at the end of their phase, they move back to their pro plan
wary belfry
What do you define as a "hold plan"?
whole mountainBOT
rapid orchid
it's stripe price that we put a user on for a user specified period of time, when the plan hits the end date the asked for, we move them back to their original plan
cloud stratus
inviso-schedule-payment
There isn't really a way to switch to a different Price and not have a charge in that case I would say
you really should change them to the Price when you are ready for the new billing cycle to start and have them pay
rapid orchid
we do
I'm trying to prevent a double pay
Normally when a user upgrades from a lower plan to a higher plan, it's not the end of a billing cycle, and on that scenario, I use proration: "none" to prevent a stripe charge. Then in the subscription updated webhook I take care of the charge myself with prorations. The reason for this is that, it's a business rule that I have to maintain the same billing cycle date, and stripe doesn't trigger immediate payment without prorations if I don't change the billing cycle.
So basically I need to prevent this method from being called, and I'm trying to figure out how can I know that stripe already made payment on this subscription from the webhook?
Or how can I know that this update was due to the plan change at the end of a billing cycle
cloud stratus
sorry I'm completely lost
and stripe doesn't trigger immediate payment without prorations if I don't change the billing cycle.
what does that mean?
rapid orchid
I know this is super complicated, unfortunately it's business requirements for a complex billing plan.
When I update a users plan, if I don't want their billing_cycle_end_date to change, then I don't change the billing_cycle_anchor. If I do this, then stripe will charge a prorated amount on the plan.
But if I don't want to prorate, and set proration_behavior: "none", then stripe won't charge anything until the billing cycle changes.
Am I correct so far?
cloud stratus
yes
rapid orchid
So to handle the edge case where, I want to keep a users same billing_cycle_end_date and not do any prorations, I have to manually charge them myself in the customer subscription updated webhook
cloud stratus
but why
what are you charging them for if you don't do proration I don't understand
rapid orchid
A pro plan on our site, can have add ons
and one specific add on, we don't allow proration on, so if a user adds the one add on, we have to charge full price, we prorate the other ones. ðŸ˜
rapid orchid
which is fine if we would allow the billing cycle to change, but the owner says we can't do that
cloud stratus
I would do the add one as a one-time Price personally so that I can update with add_invoice_items and get proration for the rest
but your way does work, just more complex. But what's the issue?
rapid orchid
well there's another wrinkle, the reloadable plans give you, site credit to spend. If you update to a pro plan, we also need to apply your remaining credit balance to the pro plan cost, which is also done in the webhook
You suggestion is probably better tho
The one edge case I'm running into is our hold plan
A user is on pro, they decide to switch to our hold plan for a couple months, so we put them on the hold plan for 2 months using a subscription schedule
at the end of the hold phase, they are reinstated to pro
and it triggers the webhook
the webhook doesn't know they were already charged by stripe, and tries to run the adjustment
so it ends up being a double charge
so I either need to prevent stripe from doing the charge on the phase change, or the webhook needs to know that this was a hold to pro change at the end of a billing cycle
cloud stratus
ahhhhhhhh
so it's not us, it's you that does it wrong. Okay that's the part I missed
rapid orchid
yes, 😄
cloud stratus
You basically want to find a way to "detect" this?
rapid orchid
correct
cloud stratus
based on how you built this I assume you're okay with a hack? 😂
cloud stratus
Either you use the previous_attributes and check if one of the previous Price was you hold one. Or you make custom metadata for the phase transition. The hack would be the latter.
rapid orchid
I think I have to do the latter, because there are scenarios where they might come of hold early through an upgrade
cloud stratus
Specifically https://stripe.com/docs/api/subscription_schedules/object#subscription_schedule_object-phases-metadata you can use that for force a metadata on your Subscription like proration_handle: 'revert_from_hold' for example and when you get that you ignore proration but then immediately go and unset that key (so that future Events don't have it)
rapid orchid
I thought of the metadata, but wasn't sure I'd have access to it in the webhook since it's a subscription update
cloud stratus
Yeah that metadata in phases shipped recently and is special:
Metadata on a schedule’s phase will update the underlying subscription’s metadata when the phase is entered. Updating the underlying subscription’s metadata directly will not affect the current phase’s metadata.
rapid orchid
oh sweet, I can live with that then
cloud stratus
you basically schedule an update to the Sub's metadata so it would be set on transition.
It's hacky because you could have some race condition but seems unlikely enough
rapid orchid
what's the race?
cloud stratus
like imagine you upgrade them seconds after the transition and now you get Events with that metadata twice
Another alternative: Look at the underlying SubscriptionSchedule and check if you just changed phase. That works too, I just am not a fan of SubscriptionSchedule's phases, they are so tough to debug 😦
rapid orchid
So you're saying if I add metadata to this phase that it will be available on the subscription later when it enters this phase?
cloud stratus
yes
rapid orchid
Then I have to manually remove the metadata from the subscription?
in case they go on hold again later
cloud stratus
yes
rapid orchid
and the race is they upgrade like a few seconds themself before the phase goes into effect?
not sure I quite understood that
cloud stratus
00:00 UTC: hold -> normal Price
00:01 UTC: normal -> Prod Price
00:03 UTC: you get customer.subscription.updated for the first one with the metadata, ignore proration and update the Subscription's metadata to unset it
00:04 UTC: you you get customer.subscription.updated for the second upgrade but it still has the metadata because you had not unset it yet
rapid orchid
oh I see, so you're saying the hold phase ended, they went back to pro, and right after that decided to upgrade their subscription but the metadata wasn't removed yet
cloud stratus
yep
unlikely, but possible. Also I took a few minutes of space but imagine your webhook is done for a day you have the same more realistic bug
but then you have devs already working on fixing it
rapid orchid
alright, thanks, I'll go with metadata for now