#horlaarsco_unexpected
vague frostBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can 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/1257413135531511921
📝 Have more to share? Add details, code, screenshots, videos, etc. below.
stiff dagger
Hello, can you send me the ID of this invoice (in_1234)? And what does "decimal payment" mean in this context?
weak basin
Okay, it generated another invoice of 0.66usd ill send the 2 invoices
in_1PXkhYASvslpl77d6Wh9xsL3 Unpaid
in_1PXpGsASvslpl77dDzJ72uZK Paid
stiff dagger
Thank you for the IDs, looking in to this
It looks like this invoice was created because you updated the subscription and said to create prorations for that update
Can you tell me more about how you were trying to add a card to pay the invoice? Not immediately seeing that in the request logs around the invoices
weak basin
Sorry i cant view that request
I just added a card via the SDK as well, i have an implementation on my end
stiff dagger
My apologies, this is the proper link to that request for you https://dashboard.stripe.com/test/logs/req_awPtEqXss3Wcle
weak basin
Checking it out
If i remove the proration behaviour is it going to work fine?
Or what do i need to set it to?
stiff dagger
If you remove that, it will default to create_prorations which means it will basically create that same prorated price but only as an invoice item that isn't on an invoice yet.
I think you will want to use proration_behavior: 'none' somehow though I forget exactly how it works with billing anchor resets. It will either create an invoice for the full amount or not create an invoice at all (I am pretty sure it is the first one). Can you try that out in test mode and let me know what you see?
If it does create an invoice, you should be able to just do that and then cancel the original invoice. If it doesn't, you can use the /pay API call to pay the invoice and then make that update with no prorations call
weak basin
Okay im trying that, why i dont want to use the pay endpoint is because its possible to increase/decrease quantity of the item on that invoice and i expect it to work, it'll work right?
stiff dagger
I think it will work that way but you'll have to test to confirm. If it doesn't, we can think of another workaround
weak basin
Okay, i would be testing this out, the problem i have with testing is i have to create a new subscription, i set the trial to 5 mins and when its past 5 mins, the invoice waits for an hour before it goes to overdue. So it's kind of been annoying to try do you have another way of trying?
stiff dagger
We have a helpful tool called test clocks that lets you simulate the passage of time https://docs.stripe.com/billing/testing/test-clocks
So you can do that and simulate the 65 minutes passing in a few seconds
weak basin
Okay i can try that
I just tried the proration behaviour of none, it created a new invoice with the amount i want to pay and paid it but the old one still exist. Is that going to be a problem?
Like would it get retried in future?
vague frostBOT
stiff dagger
I forget if it would be automatically retried, but the Customer would still be able to attempt to pay it if they have a link to the hosted invoice page. It would probably be cleanest to cancel the original invoice once the new one has been created
weak basin
Do I have to do it manually or is there another settings i can try
stiff dagger
It would need to be its own API call
weak basin
That would mean , i would update the subscription and that generates a new invoice after that is paid, i cancel the old one? Is there an endpoint that can be used to get exactly the old one, wouldnt want this to cause any issues
stiff dagger
You could list open invoices and cancel anything that comes back from that API call https://docs.stripe.com/api/invoices/list#list_invoices-status
Oh and filter by that subscription, that way you won't see one-off invoices or invoices from other subscriptions https://docs.stripe.com/api/invoices/list#list_invoices-subscription
weak basin
Okay just to confirm! Is this the only way to handle reactivation after a subscription is past due, it just seems too manual and prone to error having to cancel the invoice myself because its possible this fails or something
uncut prairie
👋 stepping in for my teammate
weak basin
Okay, I've just been investigating the most efficient way to reactivate a users's subscription after its past due, due to no card added on trial
uncut prairie
I think things went a little sideways here when the billing cycle was reset after adding the card. What you could do in future cases is add a card after a payment fails and wait for smart retry settings to kick in: https://docs.stripe.com/billing/subscriptions/overview#recurring-charges
Ah, this might be a more apt section of that doc: https://docs.stripe.com/billing/subscriptions/overview#settings
weak basin
Smart retry can take time, in my case the customer want to add a card now and pay with the card immediately but while doing this they can increase or decrease the quantity of the product
uncut prairie
I think you have a few ways you can handle this. I recommend continuing to test with this scenario in mind so you can decide on how you want to handle this in production.
So, in this case, a trial subscription was created where the end behavior for the trial is to create an invoice. When the trial ended, an invoice was created and then it was finalized ~1 hour later.
One way to handle this is to use webhooks to listen for customer.subscription.trial_will_end events to let you know that a customer's trial is ending soon. You can then have some logic on your end to prompt the customer to provide payment details. Alternatively (or in addition to), you can listen for invoice.created events to let you know the subscription's next invoice is now in draft state. You have ~1 hour before this invoice is automatically finalized, so you can decide whether to email the user again for payment details and/or ask them if they want to change quantities.
If the invoice is automatically finalized and payment fails, your settings currently transition the Subscription to past_due. At that point, the invoice is finalized and can no longer be edited so customers can't change the quantity. In order to move the Subscription back to active, they need to pay the latest finalized invoice.
Note that the auto_advance property on the last finalized invoice changes to false. This means we won't automatically try to pay it when a customer adds a card. You'll need to call /pay manually or change the auto_advance property to true
weak basin
if it is on the past due, the problem here is the user might have 10 quantity in the latest invoice but decide that they dont need to pay for 10 quantity anymore and they want to just reduce the number at that point, how do you think i should handle that?
uncut prairie
Let me do some quick testing to see what the best way to handle this is
weak basin
Thanks very much
uncut prairie
Okay, if your goal is to charge a customer now for the downgrade, you should update the Subscription to update the quantity on the subscription item to the new quantity and also pass billing_cycle_anchor: 'now' and proration_behavior: 'none'. This will reset the billing cycle so it starts now and doesn't create an additional prorated charge for the time between the previous invoice's end date to now. You can then update the status of the old invoice (with the higher quantity) to void