#ratta-tha-vermin_docs
1 messages · Page 1 of 1 (latest)
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.
- ratta-tha-vermin_best-practices, 1 day ago, 12 messages
👋 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/1235682199211344007
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
You can't really, since the test accounts don't have long delays. I can share feedback about needing a longer delay test account to simulate this sort of flow more accurate.
We allow organizations to upgrade their subscription within our app when they are on bank accounts. in a live environment the payment will then go into 'pending'. If it fails, the subscription will cancel instead of reverting back to what it previously was. Could you maybe provide some guidance of how we could revert the subscription back to what it was after it fails instead of cancelling? Or is there something else we can do? It just shows up like false churn in these circumstances.
Yea, there's another approach to take here where you control the upgrade request using pending changes:
oh, shoot
Pending updates aren’t supported when the subscription’s collection_method is send_invoice or when bank debits are used as the payment method for the subscription.
Right.
So the first thing you'd need to do is disable your cancel-on-failure logic/settings, and handle the card/bank split there
But there isn't really a smooth way to do this without pending updates.
An alternative would be doing something like calling the Upcoming Invoice endpoint with the upgraded items to simulate the upgrade and get the amount etc:
https://docs.stripe.com/api/invoices/upcoming
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
Then you could try doing a separate payment for the upgrade amount, outside the subscription
If it faisl, you leave the sub as-is
If it succeeds, you proceed to update the actual subscription to the upgraded plan, with prorations disable to avoid double charging the difference
proration_behavior=none
https://docs.stripe.com/billing/subscriptions/prorations#disable-prorations
hmmm ok interesting. this affects such a small percentage of customers we probably just need a simple solution for now. maybe just changing the cancel-on-failure logic/settings. where can i change that btw?
In your billing settings in Dashboard: https://dashboard.stripe.com/settings/billing/automatic
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
we're using smart retries
but to my recollection smart retries didn't work when source is bank account
we're using plaid integration to connect bank accounts btw
i guess this ach retry is new? does that work for plaid-attached bank accounts?
Subscription status setting is what cancels
yeah but we don't want the subscription to cancel if it's a card payment that fails more than 4 times in 2 weeks
That's what I'm suggesting, you might need to remove that setting then handle those cancels yourself once the retries are exhausted
hmmm ok gotcha
one last question
if a pending bank payment eventually fails, what webhook event is sent? And does this event carry info about what subscription they had and what they were trying to move to? We could just wait for a failed payment or invoice (or whatever) webhook then revert back to what they had instead of cancelling.
That would be payment_intent.payment_failed https://docs.stripe.com/payments/ach-debit/accept-a-payment?web-or-mobile=web&payments-ui-type=direct-api#web-confirm-paymentintent-succeeded
With the normal subscription flow, yes, you could get that info. You'd also get invoice.payment_failed and you can retrieve the subscription from there. The payment intent also has invoice so you can chain those together if you want to start from that event.
Of course you wouldn't have this info in the side-payment flow I described, you would need to track that in your own systems and/or metadata
and if we take that route, I guess we should change subscription status to 'Mark the subscription as unpaid' and then wait for a subscription.updated event that changes state to unpaid and then decide based on whether it's a card (cancel the subscription) or bank (if it was from a plan change, revert the plan, else cancel the subscription). something like that?
Yep, pretty much!
One heads up, yes
In the case where you upgrade and the payment fails, note that the subscription is already considered upgraded, and the invoice is expected to be paid
if you end up downgrading the sub again, be sure to disable prorations
Otherwise you may inadvertently credit the customer for the upgraded plan
lol
can i ask... i'm sure stripe compensates you well for doing this, but is this something you also just really enjoy? getting into the technical chats with customers and solving issues like this?
it's always interesting to me to see familiar faces in here still
It is! We help users here in Discord, and escalated developer support cases, as well as helping our colleagues investigate things internally. Everyday brings new challenges, along with some well-worn ones. Those familiar problems are just opportunities to make things easier/better for you, though.