#nstripe0_api

1 messages ¡ Page 1 of 1 (latest)

remote heathBOT
#

👋 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.

lost kettle
#

I am testing using the "Always authenticate" Stripe test card 4000002760003184

spice meteor
#

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

lost kettle
#

Isn't there a flow by which these scenarios would have the merchant contact the customer to have them perform the authentication?

spice meteor
#

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

lost kettle
#

How are Stripe Subscription recurring transactions handling this? Are they implying off_session: false?

spice meteor
#

On the initial payment or the recurring payments?

lost kettle
#

Recurring

spice meteor
#

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

lost kettle
#

Thanks, is there a test card that will perform that request for 3DS even in those off session / recurring charges?

spice meteor
#

that's the card you're using. It requires 3DS on all transactions, no matter what

lost kettle
#

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.

spice meteor
#

"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

lost kettle
#

Oh, interesting. Maybe it's a difference in how it shows on the Dashboard in this case, hmm.

spice meteor
#

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

lost kettle
#

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?

spice meteor
#

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

lost kettle
#

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?

spice meteor
#

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

lost kettle
#

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?

spice meteor
#

You can use Test Clocks with one-off Invoices