SCA may be required at payment information submit

Do you have the "Stripe review" checkout pane added to your checkout flow? 3DS integration is done through this pane.

Also, did you try updating to the latest version to see if the issue persists?

Yes - the stripe review checkout pane is active, one step after the "Payment Information" checkout pane (where the API error response happens).

And no - we are currently on 1.0-rc7. Issue ✨ Allow for payments without stripe review pane Fixed may influence the behavior in question, though I doubt it.
We well upgrade our site and report back if anything changed.

Yes - the stripe review checkout pane is active, one step after the "Payment Information" checkout pane (where the API error response happens).

Is it placed on the "review" step though?

The Steps are configured like this:

Payment

• Contact information
• Payment information

Review

• Review
• Stripe review
• Agree to legal terms

Unfortunately, I'm not currently working on projects that use Stripe myself... So perhaps worth sending an email to either @John Pitcairn or @jonathanshaw that are currently the 2 most active contributors to this project.

Just to avoid confusion those are 402 errors from Stripe API, not 403.

Not being able to reproduce it with a test Mastercard requiring 3DS auth makes followup tricky.

Are you running any custom php or js code to create customers or attach payment methods? Any issue patches?

Is it only some mastercards? Are they all issued in a specific country, or by a specific bank, or something else in common?

Are you able to push back further on Stripe support about a test mastercard number that is equivalent to one of your failng mastercards, asking for auth at payment method setup? Emphasise that it isn't possible to debug the problem at our end without a test card, or more specific documentation.

Can Stripe support confirm whether requiring authentication at payment method setup is an expected behavior, and if so can they point to the specific documentation for that?

Anyone else seeing this behavior? Please do post here.

We updated our site to commerce_stripe 1.0-rc10, however some Mastercards still get rejected - hence no difference to 1.0-rc7.
On this site only one patch gets applied 📌 Allow translating Strip error messages. Needs review No further code modifications are in place for commerce_stripe.

So far we only tracked down only Mastercards (DebitCards and Credit cards aswell). We know of some cards issued from different Austrian banks, but we can't get any details on the cards from Stripe - neither for the logs in the dashboard nor from the Stripe support.

Another chat with the Stripe support gave following suggestions:

• "Our documentation mentions that creating and attaching payment methods using the Payment Method API directly will cause these issues": https://stripe.com/docs/api/payment_methods/attach
• "What was recommended is for you to use the Setupintents API instead, or a payment intent API with the setup future usage property so a payment is taken and method is saved at the same time"
  https://stripe.com/docs/payments/save-and-reuse
  https://stripe.com/docs/payments/save-during-payment

Asking for test card-numbers wasn't very helpful, I just got reminded to have a look at https://support.stripe.com/questions/test-card-requiring-3d-secure-authe...

Uh-oh. Thanks for persisting with Stripe support @guedressel.

I think we are indeed using the attach endpoint directly when we call $stripe_payment_method->attach() in Stripe::doCreatePaymentMethod().

Changing the issue title to broaden the scope, there might be considerable work involved. Something like:

• Create a Stripe Customer and SetupIntent from card form javascript submit.
• This may trigger a 3DS auth request at billing info submit, and we need to be able to handle that.
• Use the payment method returned for Stripe::createPaymentMethod()
• Stripe::doCreatePaymentMethod() may need changes.
• Stripe::createPaymentIntent() may need changes.
• Probably other issues as a result.

SetupIntents API docs: https://stripe.com/docs/api/setup_intents.

Getting this right should help provide a buffer against the pace of change, and might resolve a few other people's hard to reproduce bugs, especially with commerce_recurring in the mix.

Stripe API docs state:

By using SetupIntents, you ensure that your customers experience the minimum set of required friction, even as regulations change over time.

So I vote for using SetupIntents over PaymentIntents with "setup_future_usage".

I also discovered, that the PaymentMethodAddForm already creates SetupIntents for authenticated users:
https://git.drupalcode.org/project/commerce_stripe/-/blob/8.x-1.0/src/Pl...

Though I don't understand yet why this happens that way. This code was created in context of #3039032: 3D Secure 2 →

Today I undertook a mind-boggling dive into the sources of this module to find a path to implement SetupIntents and overcome the shortcomings with strong 3DS checks.
I learned a lot about the structure of commerce, commerce payment, commerce checkout, the Stripe API and - last but not least - commerce stripe 🤓

After some back and forth I might have found a quite straight forward modification to use SetupIntents. It was especially easy since SetupIntents were already in place to add payment methods outside a checkout flow.
I'll create an issue-fork to show you what I came up with. It's supposed to have a foundation to iterate on - and to build UnitTests.