#[LBG] India - connect
1 messages ยท Page 1 of 1 (latest)
No
I believe it should work. Please try it in test mode first
OK let me try
Even when the Express account is rejected, I am still asked the password for the associated mail during onboarding for standard
Should I wait a little ?
Doesn't look like you actually deleted it: https://stripe.com/docs/api/accounts/delete
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
Seems to work ๐
I'll try on live (with partners account)
Are you able to see my live objects if I send you one ? I have questions on rejected subscription payments
And payment_intents
Yes. What's the object and question?
A few weeks ago, we had problems with Subscriptions. We saw our churn explode because of unpaid subscriptions, 90% with "insufficient funds" bank reject messages. All our metrics went down, MRR, active subscriptions, etc. And the churn exploded. The best guess we did was the SCA, because we weren't SCA compliant. We operate in EU and were credit cards objects and not payment_methods that can be authenticated by the card issuer. Nothing was indicating that it would be SCA though, from reports like this one : https://dashboard.stripe.com/authentication?startDate=2021-12-13&endDate=2022-03-13 were not indicating SCA attempts at all. We bet on the hypothesis that as the card object itself can not be authenticated, the card issuer would never try to ask, therefore sending "default" reject messages. So we went SCA compliant creating payment_methods with off_session set to true. All our new payment_methods should now be SCA compliant. The same report shared upper shows that it has a positive effect. In fact, all our metrics are green, MRR going up again, active subscriptions as well, churn going down again. All good, but this makes me think that the bank reject messages are not reliable at all !
Hey @vernal plinth, I'm stepping in here fro @vale minnow as he needed to step away. Can you share a specific subscription that saw one of these errors?
I have a list of unpaid Subscriptions with a payment_method that should be authenticated, is there a way to know more about this ? Some samples (pi_3KbErSLJLkeHRLt11qLSJCp2, pi_3KcVxBLJLkeHRLt10zDce5Uz, pi_3KcSXMLJLkeHRLt11yaxjAOD,pi_3KcIWoLJLkeHRLt11zpIFO5N,pi_3KbV4RLJLkeHRLt11kDfXc3v,pi_3KcyBqLJLkeHRLt10DYPxP0M)
Hi @acoustic bay, sorry for the long messages, I want to give as much info as I can to be efficient
ok
So initially, SCA definitely could have been the issue. However, I can see that you are setting up these PaymentMethods with a SetupIntent now, so you are doing everything right.
Insufficient Funds is one of the more common decline codes that an issuer uses.
Nothing is jumping out to me as being wrong from your end.
Is there a way to dig further in this ?
Yeah, I'd contact Support about this. They can help with decline analysis.
We don't have a rich target that is true but I am persuaded banks are blocking for unknown reasons
Speaking about setupintent
It is possible. Oftentimes the best way to get more info is actually to ask your cardholders to contact their banks as that is the only way to get the true reasoning from the issuer for why they declined.
Ok
I'll contact support to know more about this, but I don't think they really helped when I asked about it last time
About setup intents, I noticed something. For every payment_method added, there is 2 setup intents canceled a few minutes after the one that succeeded
I found this by looking at fingerprints logs, some sample : oq03cc1AKCRtndU4, mzkeEqVVcRogLfHQ, xdT5LZmml0AAFFQf
Those fingerprints are source of paid but also unpaid subscriptions
Can you provide the SetupIntent IDs for those 3?
I'll look at the canceled ones to see if I can see anything
seti_1KbnfFLJLkeHRLt1WAGCiUBG, seti_1Kc7jDLJLkeHRLt1gdtSp9ZQ, seti_1Ka8N2LJLkeHRLt1bPtPydFl
That's the 3 unique succeeded ones
Yeah so all 3 of those look to have successfully set up 3DS. This doesn't guarantee that the card won't decline for a different reason upon payment though.
Sorry, I'm still not seeing anything here that doesn't just look like normal bank declines to me...
How can you tell that 3DS has been asked from the logs of the setupIntent ?
From this event ? evt_1KbnidLJLkeHRLt1i9GECHQz
"status": "requires_action" and three_d_secure_2_source keys maybe ?
Yep exactly, if it has a status: requires_action then that indicates 3DS is required.
About the setupIntents, why a successful seti (seti_1KbnfFLJLkeHRLt1WAGCiUBG) is always followed by two seti canceled (seti_1KbnjNLJLkeHRLt1NUJxH3WM, seti_1KbnjOLJLkeHRLt1HQDBPWbE)
Ah okay. You are using a trial period.
With a trial period we provide you a SetupIntent upon Subscription creation.
Take a look at req_1a9sCf5FGVePoR
You can see we return you a pending_setup_intent
Ok so that is normal behavior ?
The first seti that is successful is to save the payment_method, and the others for subscriptions, but why 2 ?
We only create 1 sub
Oh interesting. Didn't notice those were from the same Sub creation.
Let me look more
Yeah it's not that obvious to link everything for a same customer
Kind of stumbled upon it by chance
Alright so this does look to be a bug.
We shouldn't be creating multiple SetupIntents here.
There should only be one pending_setup_intent created upon the Subscription creation.
Nope, nothing wrong on your end.
And no real impact to you.
Just extra SetupIntents on your account.
Coming back
We are filing internally to get this bug fixed up. But yeah, shouldn't actually have any impact.