#japoorv-authentication

1 messages · Page 1 of 1 (latest)

young crystal
simple rune
#

Do you have the id of this subscription? (sub_!23)

vague drift
#

sub_1JfmS8SGbEHxf91bY6SLla4b

simple rune
#

Thanks!

vague drift
#

Any update ?

simple rune
#

Still looking. I do not see the usual things that would cause the state to go to requires_action

#

I am still looking in to the way, that just may provide direction

vague drift
#

So I am just updating the subscription with proration_behavior to always_invoice and I am expecting the invoice to be automatically paid (if the payment method doesn't require any authentication which in this case is).
I want to know whether there is something wrong with my approach or there is something wrong with the card.

abstract spire
#

I'm stepping in for Pompey for a bit, looking

vague drift
#

Cool thanks

simple rune
#

So it looks like this may have been invoked by something that forces 3DS authentication for any cross border payments

#

I think it is because of the location of the 4242 card vs your account. Can you try a subscription with pm_card_in or 4000003560000008 to see if they do not run in to this error?

vague drift
#

This is rather the 3DS card. So this actually has authentication won't this require authentication every time we update ?

#

Moreover it says that non-inr cards require cards from outside (compliance regulations). So this doesn't work either.
I think the issue is that the unauthentication card is also requiring authentication.

abstract spire
#

hello @vague drift , clarifying one thing: 4242 does support 3ds as a test card. In this case, I think IN accounts according to https://support.stripe.com/questions/faqs-for-setup-intents-and-payment-intents-api-recurring-charges-from-indian-cardholders will require authentication when the cards support it so that is what you're seeing

vague drift
#

Ah that clears it up.
Thanks @abstract spire I can see how difficult it would have been for you to pinpoint it.
Thanks a ton !!