#ratta-tha-vermin_docs

1 messages · Page 1 of 1 (latest)

lean shardBOT
worn duneBOT
#

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.

lean shardBOT
#

👋 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.

dawn hemlock
#

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.

vapid pawn
#

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.

dawn hemlock
#

Yea, there's another approach to take here where you control the upgrade request using pending changes:

#

oh, shoot

vapid pawn
#

ya we're doing that for cards

#

but it says it doesn't work for bank accounts

dawn hemlock
#

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.

#

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

vapid pawn
#

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?

dawn hemlock
vapid pawn
#

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?

dawn hemlock
#

Subscription status setting is what cancels

vapid pawn
#

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

dawn hemlock
vapid pawn
#

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.

dawn hemlock
#

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

vapid pawn
#

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?

dawn hemlock
#

Yep, pretty much!

vapid pawn
#

haha messy but do-able i guess

#

any other suggestions?

dawn hemlock
#

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

vapid pawn
#

got it!

#

you've been here for a long time... i remember back in Stripe's IRC days.

dawn hemlock
#

😄

#

It's been some years, yes 👴

vapid pawn
#

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

dawn hemlock
#

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.

vapid pawn
#

I think that's great

#

Thanks again for all your help!

#

Have a great day today!

dawn hemlock
#

Quite welcome -- you too!

#

Thanks for sticking with us all these years, too 🙂

vapid pawn
#

We've had some version of a Stripe Account since 2013 i think

#

so been some years for us too 🙂