#nstripe0_api
1 messages ¡ Page 1 of 1 (latest)
đ 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/1334989932250267699
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
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.
- nstripe0_api, 3 days ago, 16 messages
- nstripe0_api, 4 days ago, 6 messages
I am testing using the "Always authenticate" Stripe test card 4000002760003184
Hi there. This seems expected to me. You've told Stripe in the API request that the customer isn't present, so authentication is not possible
Isn't there a flow by which these scenarios would have the merchant contact the customer to have them perform the authentication?
Yeah, I think you'd have that scenario if you remove off_session: true
in which case the PaymentIntent would transition to requires_action and you'd have to bring the customer on-session and have them authenticate
here's the general guide as a starting point on 3DS: https://docs.stripe.com/payments/3d-secure/authentication-flow
How are Stripe Subscription recurring transactions handling this? Are they implying off_session: false?
On the initial payment or the recurring payments?
Recurring
They would be flagging the payments as off session when we send the charge to the network, but there is realistically no card that behaves the same was the 3184 test card does
In localities where SCA is in effect, off session and recurring payments are still allowed with the appropriate setup, though it is true that the issuer can request 3DS even on these off session or recurring charges.
Additionally, Stripe Billing offers settings where we can email the customer if 3DS is required on a recurring payments when it is required
Thanks, is there a test card that will perform that request for 3DS even in those off session / recurring charges?
that's the card you're using. It requires 3DS on all transactions, no matter what
Right, however it does not seem to leave the Payment Intent in the Incomplete state (giving the option for contacting the customer to complete it by supplying additional authentication), it seems to result in the Failed state.
"failed" is not a status a PaymentIntent can have
in req_QGQui9HjZOGyZX your PaymentIntent's status afterward is requires_payment_method
So you can still bring your customer online and try to confirm the PaymentIntent while they are present to authenticate
Oh, interesting. Maybe it's a difference in how it shows on the Dashboard in this case, hmm.
Sometimes there are dashboard-only badges that are shown that don't map to what is happening in the API. I recommend always looking at the properties on the actual object
Can you help me understand why this request's payment intent is left in the requires_payment_method state rather than requires_action for the 3DS flow?
because in the scenario when you're trying to create/confirm a payment off-session and 3DS is required, we treat that as a decline. You can read the error_code to know that you could complete this payment by having your customer come on-session to authenticate
when a decline happens, a PaymentIntent's status transitions to requires_payment_method
Could you take a look at a live mode payment intent here: pi_3QnKn0FOrEmR4dyh0Ssvzqdf
This is a recurring payment using a Stripe Subscription.
This is essentially the case I'm trying to reproduce so that we can figure out how to handle it.
In this Payment Intent, it does not result in a decline, why is that?
Gotcha. Why try to create it with a one-off paymentintent, though? Why not use an Invoice? The way to reproduce would be to run a SetupIntent on the 3184 card and set it as the Customer's invoice_settings.default_payment_method and then create the Invoice
You can use test clocks: https://docs.stripe.com/billing/testing/test-clocks
The payment flow this takes is different, not using Stripe Subscriptions.
Is this result different because one is using an Invoice and one is not?
You can use Test Clocks with one-off Invoices