#[LBG] India-billing-sca
amber cobalt
Hey there. Can you share some object IDs so I can get an understanding of how you're integrating? What you're describing is sounds a bit complex and not the recommended way
fallen ice
Hi, here is the id of a customer that failed with our new SCA integration : cus_LVMCJ5keaFN1Vh
What we do is create a customer on client sign up. When he wants to subscribe, we create a checkout Session on subscription mode we a 3 days trial
The SCA authentication flow goes for 0€, 3 days later if the customer hasn't canceled his sub, the payment goes for 34€ (29€ + Stripe Tax)
34€ won't we exempted and the "34€" are not authenticated
I think this integration works fine with a subscription without trial as the customer's initial payment is on session, other payments should roll on
But we use trial
amber cobalt
Taking a look at cus_LVMCJ5keaFN1Vh to understand why the payments are failing
This is the underlying invoice Payment Intent that is failing: https://dashboard.stripe.com/payments/pi_3KpSQCLJLkeHRLt11SAqkaEr
Looks to me like the payment was decline because of insufficient funds. Nothing related to SCA
fallen ice
98% of our failed payments are "insufficient funds" and we have high rate of payment failed. Back to February when we were using card objects and not payment_methods (so not SCA compliant at all), we tended to 100% failed payments because of "insufficient funds". I do not trust this default error code. I am not saying it's Stripe's fault
What would be the best SCA compliant workflow that includes trial ?
Wait
At the end of the Checkout Session flow in subscription mode, we use this : https://stripe.com/docs/js/payment_intents/confirm_payment
But we should use this : https://stripe.com/docs/js/setup_intents/confirm_card_setup
No ?
amber cobalt
The way you're integrating is SCA compliant. The way Checkout works in mode: 'subscription' where there is not initial payment due (i.e. a free trial):
- Creates a Setup Intent (the €0 charge you referred to) for auth the card via 3DS for future recurring off-session payments: https://dashboard.stripe.com/setup_intents/seti_1KoLymLJLkeHRLt13aPTtCJY
- This successful Setup Intent creates an authenticated Payment Method object which is used for these payments (
pm_1KoLylLJLkeHRLt1x2C7nM2U) - Any future invoices where payment is due (i.e. after the trial ends), we attempt to charge that
pm_xxxobject: https://dashboard.stripe.com/payments/pi_3KpSQCLJLkeHRLt11SAqkaEr
amber cobalt
But we should use this : https://stripe.com/docs/js/setup_intents/confirm_card_s...
No, you don't need to use that with Checkout. Checkout handles all that
Those methods are for custom, non-Checkout flows
fallen ice
Indeed we do not use it in this workflow
We only create a Session in subscription mode and that's all
amber cobalt
Yup, that should be sufficient. In the particular payment you've outlined the bank has declined it with an insufficient funds errors
It could that that error is correct and the card does not have the funds to complete the payment, or that it's the wrong error
But there's no indication that that payment was declined because 3DS/auth was requested (which can happen for off-session payments even if they're 'setup' correctly)
fallen ice
Do you confirm that this setupintent : evt_1KoLynLJLkeHRLt1t48mwtCA required 3DS authentication, and that the customer correctly authenticated with : evt_1KoLzMLJLkeHRLt13y3IY5bj
amber cobalt
Yep, 3DS was requested (status: 'requires_action') on creation and the success event indicates it was authenticated correctly
fallen ice
Could the amount for the initial payment (0€ because it's a trial) used when authenticating the payment method via 3DS be a problem for a payment off_session of 34€ 3 days later ?
amber cobalt
What do you mean 'a problem'?
fallen ice
By problem I mean that the credit card is authenticated for 0€ and not 34€ ?
amber cobalt
In theory, no. The goal of the process is to authenticate the payment method for any off-session recurring payments regardless of value. That's not to say that the bank/issuer may request auth for a future payment, which can/does happen
But there's no way to authenticate the card for a specific value. It's just often that it's presented as €0 charge to the user
amber cobalt
What do you mean?
fallen ice
Every payments are blocked since our last SCA integration with Checkout
We're missing something.....
amber cobalt
Checkout is SCA compliant. There's no additional configuration required for you to enable that, it just works out of the box
As stated, the issue about that payment/subscription you've shared does not indicate an SCA related issues
fallen ice
Could our account have a "bad reputation" in the eyes of issuers anti fraud systems like mailing systems due to our non-SCA integration a few month ago ?
amber cobalt
Are you noticing any patterns with the insufficient funds errors? Are they from the same issuers/banks?
fallen ice
How can I check this ? Without going failed payments one by one
I do not have Issuer name in the export log
fallen ice
brittle owl
Hi! For these types of questions I recommend asking the Stripe Support directly here: https://support.stripe.com/?contact=true
Make sure to include all relevant information, like PaymentIntent IDs, the screenshot you just shared, etc. And they should be able to help you!
fallen ice
Hi, What if I find a pattern regarding insufficient funds coming from an issuer or bank ?
What can we do ?
brittle owl
I'm not sure unfortunately, so I recommend to contact Stripe support directly.
fallen ice
How to find the Issuer name through API from the PaymentIntent ? Should I expand the payment method object ?
brittle owl
In the payment method object, you can find a lot of information about the card used: https://stripe.com/docs/api/payment_methods/object#payment_method_object-card
fallen ice
There isn't the issuer name