#Austin_Rowe
1 messages · Page 1 of 1 (latest)
Hi đŸ‘‹ I'm not sure I'm following the question. All our Payment Intents require confirmation, it is a standard part of their lifecycle.
If you look at this section (7) https://stripe.com/docs/payments/save-and-reuse?platform=web#charge-saved-payment-method it will familiarize you a bit more with what I'm trying to accomplish. Note that we're doing a charge for the connected account though
If the payment method is one that doesn't require additional authentication then it goes through, but if it's one that requires authentication for subsequent payments it will cause the error I'm trying to fix
You can see the different payment scenarios it mentions in this section https://stripe.com/docs/payments/save-and-reuse?platform=web#web-test-the-integration
If I use the third card option that has this description The card requires authentication for the initial setup and also requires authentication for subsequent payments. then it requires additional verification everytime we try to collect a payment
The error that you referenced above isn't about an authentication problem, that error is thrown when you try to use a Payment Method more than once without attaching it to a Customer.
I'm only trying to use it for one payment intent, it's just that if the card requires additional verification the docs say *When a payment attempt fails, the request also fails with a 402 HTTP status code and the status of the PaymentIntent is requires_payment_method. You need to notify your customer to return to your application (for example, by sending an email or in-app notification) to complete the payment. Check the code of the Error raised by the Stripe API library or check the last_payment_error.decline_code on the PaymentIntent to inspect why the card issuer declined the payment.
If the payment failed due to an authentication_required decline code, use the declined PaymentIntent’s client secret and payment method with confirmCardPayment to allow the customer to authenticate the payment.*
Can you share IDs of objects that you're using in testing?
Here's the failed payment intent id pi_3LQbgcFwRyDlBFez10DV43i5
Here's the charge id ch_3LQbgcFwRyDlBFez1HJIQHWq
Would it help if I outline the process to get to the error?
You're trying to use the same Payment Method twice without attaching it to a Customer. You pass it once when you create the Payment Intent, and then attempt to use it a second time when you create the subsequent confirmation request.
Is it possible to check if it will need confirmation before creating the payment intent and then if we do need additonal authorization trigger the confirmation steps, then after the user gets authorization pass it along to the payment intent?
We're trying to avoid cloning the customer obj onto the connected account so we don't have many customer objs to keep synced
No, the confirmation step is when we reach out to the issuing banks, and when we would find out whether they require authentication for the transaction.
So in order to use a saved payment method that will require authentication in a connect app we are FORCED to clone the customer along with the payment method to the connected account that will receive the payment and after the payment intent has failed trigger an auth action on the user side so they can confirm their card?
Do you know approx what percentage of cards are ones that require additional authentication?
Yes, in the flow you described the Payment Method needs to be used more than once, so you would need to attach it to a Customer (though you don't need to bring all the customer details down to the connected account if they aren't pertinent to your flows).
Alternatively you could look at re-cloning the Payment Method if you hit an authentication error, and then go straight into an on-session flow with the Customer present.
I don't have a good estimate of how often this happens. Behind the scenes we're requesting an SCA exemption from the issuing bank if a card has been authenticated previously, but it's up to the issuer to decide whether they will grant that exemption request.
Hmmm on-session.... is there documentation somewhere for charging a saved payment method in an on-session fashion?
Really the customer is on the site and triggering the off-session transaction I just have only found documentation that shows charging a saved payment method in an off-session format
All we're trying to achieve is a flow that allows a user to select their saved payment method and then to pay with it instead of having to input their card details everytime.
Note that it is a payment to a connected account though
btw thanks for your help @slow dune I really appreciate your time
Gotcha, and it looks like you're using direct charges.
I'm looking to see if we have a guide that covers just the on-session with an existing Payment Method approach, but will summarize the flow in case I can't find one.
You'll create a Payment Intent for the payment, and while doing so you'll:
- make sure to not pass the
off_sessionparameter - make sure to not pass
confirm=true(you'll confirm client-side later) - pass in the ID of the Payment Method to use in the
payment_methodparameter
Then once you have created the Payment Intent, in your client-side code you call the relevant confirm method for the type of payment method being used:
https://stripe.com/docs/js/payment_intents/payment_method#confirm_payment_intent_payment_method
It's similar to this flow, but skips Step 3 since you already have the card information:
https://stripe.com/docs/payments/accept-card-payments
I'll try it out! Thanks @slow dune