Niek

[fierce epoch]

hi! well generally there's a distinction between an on-session and an off-session payment(customer initiated or merchant initiated). Changing a plan and invoicing for the change is on-session, and that generally requires 3DS all the time(off-session payments like recurring invoices can get exemptions for 3DS)

so really you just have to handle it, you should present the payment_intent.client_secret from the Invoice on the frontend and have the customer authenticate

[finite bloom]

Hi Karl, thanks to confirm. I prefer to do this 3DS check before doing the subscription change, so before the invoice is generated. If the check fails (eg because the customer forgot his digicode) I don't want the change to go through. Is there a way to confirm the existing payment method as a step just before the actual subscription plan change?

[fierce epoch]

no, it doesn't work that way really.

when you attempt the payment, the bank might decline it and require 3D Secure. Doesn't matter what happened before, when you actually attempt the payment, 3DS might be needed. The correct way to handle it is to handle that '3DS required' outcome

you might be able to use https://stripe.com/docs/billing/subscriptions/pending-updates to allow for an easy rollback if the payment fails/isn't authenticated

[finite bloom]

I see thanks. Indeed the problem is then to rollback the subscription that was already changed. I will look into the doc