#sai_rez-sca-test-cards
remote condor
sai_rez-sca-test-cards
Hey there! 4000002760003184 requires 3DS/auth approval for all transactions. So if this is an off-session transaction (likely is with an invoice), then it'll just fail as the customer isn't there to complete auth
tawdry wagon
Thanks for getting back, we have a flow where users with failed payments can update their card and retry to become active users. We use confirmCardSetup then later on in the logic we pay the invoice using stripe.invoice.pay
Shouldn't authentication work when running confirmCardSetup?
remote condor
Can you share the ID of a PI which is behaving this way?
tawdry wagon
"pi_3KOKnYKl7yri9QNL0tNBntJL"
cus_L4TiIgrZSr6YoB
I included the customer number in case
remote condor
Yep, it's a PI stemming from an invoice/subscription. Naturally they're off-session (your customer won't be on-session for recurring payment)
So it's totally expected that that card fails
tawdry wagon
Would you recommend we use confirmCardPayment instead or in the backend use stripe.paymentIntents.confirm?
remote condor
You should always use confirmCardPayment in the front-end! But it doesn't matter in this instance, it'll fail regardless
tawdry wagon
Ah okay, what would you recommend to handle this scenario?
remote condor
You'd need to bring your customer back on-session to re-attempt payment and authenticate
tawdry wagon
I didn't quite understand, if I were to replace confirmCardSetup with confirmCardPayment, and then attempt to pay the invoice, why would it fail regardless?
remote condor
Because the card you've associated with that subscription for payment requires authentication for every payment (regardless of if it had been setup for off-session payments).
So in those instances, yes you'd use confirm method from Stripe.js to carry out 3DS/auth whilst your customer is on-session.
But the nature of this payment is a recurring invoice from a subscription. As such, its marked as an off-session Payment Intent and by default will fail as there's no customer present to complete the auth steps needed.
In those off-session instances where the bank requests 3DS/auth, you need a recovery flow to bring your customer back online and to re-attempt the invoice payment and complete the 3DS flow.
Does this make sense?
tawdry wagon
Yes that makes sense, so having users go through authentication using confirm methods is pointless in this flow as they would have to authenticate twice correct?
Also sorry for all the questions, what is the function of stripe.paymentIntent.confirm()?
remote condor
go through authentication using confirm methods is pointless in this flow as they would have to authenticate twice correct?
I don't understand this part
remote condor
Also sorry for all the questions, what is the function of stripe.paymentIntent.c...
That's for a manual confirmation, which we generally don't recommend: https://stripe.com/docs/payments/accept-a-payment-synchronously
tawdry wagon
So as I mentioned above we use the confirmtCardSetup which triggers the modal to authenticate and then pay the latest invoice which as you mentioned is off session so would require the user to come back on session to trigger a modal again and authenticate, would this be correct?
tawdry wagon
That would trigger a modal too? and you mentioned it wouldn't matter, is that right? Sorry if I misunderstood
slate spire
it would trigger a modal if the payment requires 3D Secure
tawdry wagon
Yea in the case of using the SCA test card ending in 3184, that would be the case?
slate spire
where users with failed payments can update their card and retry to become active users. We use confirmCardSetup then later on in the logic we pay the invoice using stripe.invoice.pay
like, don't do that. Just simply call confirmCardPayment with the customer's new card and the client_secret of the invoice.payment_intent, that will pay the invoice(presenting 3D Secure if needed) and save the card at the same time.
you should ~never be calling stripe.invoice.pay (since it doesn't handle 3D Secure), you should be confirming the PaymentIntent that belongs to the Invoice.
tawdry wagon
You should always use confirmCardPayment in the front-end! But it doesn't matter in this instance, it'll fail regardless
Okay that makes sense, I was confused from the comment above as your colleague made it seem it wouldn't make a difference?
Going off what you said should we not use stripe.invoice.pay at all in general or only omit from an SCA flow?
slate spire
by 'fail' they meant it will require 3D Secure.
slate spire
Going off what you said should we not use stripe.invoice.pay at all in general o...
in general you should never use it(all flows are SCA flows, 3D Secure is a global thing)
it(the invoice pay endpoint) is something we have vague plans to remove one day(nothing concrete, but just for context, it's something that is mostly deprecated)
tawdry wagon
Okay that's good to know, It certainly added more complications for us, I'll review our code and refactor, thanks for being patient
tawdry wagon
Hey, @slate spire following your advice, I got the payment intent client secret from a subs latest invoice and card to use with confirmCardPayment. However, when updating the user in our flow we receive this error message
Error attaching payment method: This PaymentMethod was previously used without being attached to a Customer or was detached from a Customer, and may not be used again.
viral summit
@tawdry wagon do you have a concrete example? Are you passing off_session to the Subscription creation?
tawdry wagon
Hi @viral summit this the customer ID for the test account
cus_L4XmTeRU7I1Sji
Above in the thread I've described the flow I am testing, it's relating to a user paying an overdue invoice when using an SCA card ending in 3184
viral summit
Can you share the exact PI id?
tawdry wagon
"pi_3KOOjQKl7yri9QNL12xW9JTT"
viral summit
thanks! looking
viral summit
Okay I'm sorry I'm quite lost, that customer has so many API Requests
Can you do a completely clean/new customer and do just the exact calls involved in the flow until it fails?
But I think the problem is that the invoice you are trying to pay is flagged as "off session" and so when you confirm the PI it doesn't properly attach the subscription to the customer
This is something we discovered recently and are looking into
tawdry wagon
Okay to give a general overview of the flow in our app to point of failure so you can make better sense of the api requests. I am trying to test a flow for when a user has a failed payment and is updating their card and paying their invoice
- create new subscription
- detach old card and attach insufficient fund card
- End end the trial and retry the payment
- Enter new SCA card details ending in 3184
- run confirmCardPayment and get paymentMethodId
- Attach paymentMethod to customer - Failure
Give me one moment to go through this and send you the customer and payment intent id
payment intent: "pi_3KOQ3ZKl7yri9QNL166vG8uG"
customer id: cus_L4ZAvIfGy1aOZF
viral summit
yeah it's the same issue unfortunately and this just doesn't work today 😦
I don't think it works but can you try changing the PaymentIntent before confirming? You want to set setup_future_usage: 'off_session' on it but I think it'll error
tawdry wagon
The payment intent is retrieved from the latest invoice, are you saying to try create a new one to pass to confirmCardPayment?
Also could you give more overview of the bug, is this something with Stripes API that hasn't been fixed yet?
viral summit
It's a limitation that we haven't been able to fix properly yet. Basically if an Invoice is tagged to be paid off session (normal for recurring invoices from a sub) it's supposed to use a previously saved card and so we don't configure the associated PaymentIntent properly. It has setup_future_usage: null since there's no need to set up the card, it's already set up/attached
But in your case the payment fails so you get the customer back on session to pay with a new card. That works but the card is not saved unfortunately
And so what I am asking here is for you to quickly test and try to call https://stripe.com/docs/api/payment_intents/update right before you try to confirm client-side, to see if that works
I don't think it can work, usually we "lock down" the PaymentIntent when created from an invoice, but that's what I'd want to double check
tawdry wagon
Thanks for clarifying, I will have to test tomorrow.
So if the payment intent had setup_future_usage set to off_session, would it have worked?
viral summit
yes
but I just don't think you can change it
that's the thing we need to fix internally, it's just not an easy fix 😦
tawdry wagon
I understand, is there a recommended flow in the meantime if in case the update call does not work?
viral summit
no 😦
The best option is likely to do a SetupIntent first to collect the card details and then try to pay the PI with it
and if it fails, try another SI. There isn't really a better approach but it's a lot more code/calls unfortunately
tawdry wagon
Well our initial approach was using setup intents and then paying the invoice, however with the card ending in 3184 the flow fails as it requires authentication on all transactions as it's off session and users need to be on session to pass
That's when your colleagues explained I should use confirmCardPayment and not pay an invoice directly as it's soon to be deprecated
If nothing can be done in the meantime it's fine, we'll have to think of another flow for users, i appreciate you looking in to it
viral summit
Sure but that card is a test card just to trigger a specific edge-case, it's not a real card. And also you can confirm the PI on session so it wouldn't trigger the card
tawdry wagon
I read users in India will require authentication on all transactions if i'm not mistaken, this would affect users there right?
As to your last point do you mean passing false value to handleActions?
viral summit
that doesn't really matter for India because you will still confirm on session
and not sure what handleActions has to do with it but I didn't mean that
tawdry wagon
Ah okay that's good to know
What did you mean "confirm the PI on session so it wouldn't trigger the card"
viral summit
The card you are using explicitly fails for off session payments. But you're already bringing the customer back on session with your current flow, so it's not going to be off session so the card won't fail
tawdry wagon
I'm sorry I'm a little confused, which method are we discussing, using confirmCardPayment approach or creating a setup intent and pay PI?