#jack-subscriptions
latent belfry
hi there, reading...
they shouldn't necessarily require doing 3D Secure again, since that falls into a specific exemption category(https://stripe.com/ie/guides/strong-customer-authentication#merchant-initiated-transactions-including-variable-subscriptions) . So if you integrate in the normal ways we document, what would happen is the customer does 3D Secure on the first payment, and then we claim that exemption on all future payments for the subscription. It should work, but the bank can potentially require 3D Secure on any payment. There's no real known issue here though or specific problem with that specific setup.
austere lantern
So it seems like a strange scenario. Ideally its a fixed subscription rather than variable, its not like EVERY month the user is being charged differently. Its just the first.
I think how its handled by other "big tech" companies is to have the initial auth be for the full amount, but then only charge a discounted value, and therefore the user is authed against a fixed subscription rather than variable. (I used to work for a "big tech" company, but was working adjacent to the payment systems so only have passing knowledge)
What I'm trying to avoid is having high drop off users due to requiring subsequent 3D Secure post-firstPayment.
Stripe's new API lets you authenticate a card when it's being saved for later use and mark subsequent payments as "merchant-initiated transactions."
From your docs^
Have you got a link to an API reference to how this is done?
Particularly the marking of subsequent payments as MIT
latent belfry
So it seems like a strange scenario. Ideally its a fixed subscription rather tha...
there's no reason to expect a large drop off, this exemption works well in practise as far as I know, so I don't actually think you have anything to worry about! But we don't have any direct data I can give you, these are still the kind of things we are analysing internally now that SCA is being enforced more in production, so we don't have anything ready to share right now. But like I said, no known issues.
latent belfry
Particularly the marking of subsequent payments as MIT
the guide there is talking about using SetupIntents(or a PaymentIntent with setup_future_usage ) and then subsequent PaymentIntents that are confirmed using off_session:true , so https://stripe.com/docs/payments/save-and-reuse for instance. It's off_session that's used to signal the payment is potentially a MIT
but if you use our Subscriptions API that's all done for you, the recurring invoice payments are automatically off-session and we claim the exemptions we can, you don't have to do anything special beyond just following the guide for creating the Subscription at the start so the first payment goes through 3D Secure
austere lantern
I use Checkout at the moment for integration. So do you think I need to do anything here? Or will they automatically be marked appropriately?