#xSummerFortx-subscriptions
1 messages · Page 1 of 1 (latest)
hi! I don't that's really the way to think about it.
The way it works is:
- you update the subscription
- the update might create proration items for the changes
- if there's an amount to pay ,that might need to charged to the customer immediately(depends what
proration_behavioryou used when doing the update) - that payment is a regular payment and like any other payment, it might decline, or it might require 3D Secure, and that has to be handled.
We used invoice_immediately
The invoice is generated too. But auto-debit for that invoice fails. And the console gives the reason as : Requires Authenticatino
yep! all makes sense and aligns with what I described above.
The invoices generated on my billing anchor date get paid successfully. But only this invoice fails. The one that is created when a subscription is updated
Is there a way to disable 3D Secure for this invoice?
nope, it's a regular payment and like any other payment it might be declined or require authentication, it's up to the customer's bank ultimately
maybe the bank grants an exemption for fixed interval recurring payments and doesn't for these off-cycle payments, hard to say without digging into a specific example
What would be the method to handle this? How do I get the user to authenticate the transaction?
I am actually using a test card for this.
VISA (USA) 4242 4242 4242 4242
you take the invoice.payment_intent.client_secret and call https://stripe.com/docs/js/payment_intents/confirm_card_payment#stripe_confirm_card_payment-attached on the frontend with the customer which lets them authenticate and will pay the invoice
or send them a link to the hosted invoice page which is a Stripe hosted page where they can pay the invoice and complete any needed authentication
invoice.hosted_invoice_url
you probably have a Radar rule that forces 3D Secure on that test payment, hard to say without a specific example to look at. But either way this can happen in livemode, for the reasons above