#bertiespell-3ds

1 messages · Page 1 of 1 (latest)

bright sparrow
#

that link is not relevant really since you are not an Indian Stripe account

#

everything works very differently in India

gentle grotto
#

that link is not relevant really since you are not an Indian Stripe account

Does is not affect us since some of our customers are in India?

bright sparrow
#

for the rest of your question, if you want an analysis on trends or to raise what you think might be systemic issues, you should write to our support team at https://support.stripe.com/?contact=true so they can do it

bright sparrow
#

your issue is your integration does not support "authenticate the card when saving it" since you attach directly instead of via a SetupIntent

gentle grotto
#

you should write to our support team at https://support.stripe.com/?contact=true

I guess this is the only way we can know whether there is a change with a specific bank then, by asking here? (We have a list of request IDs that all fail in this way, and which we don't think used to, but it sounds like that is a better place to ask?)

bright sparrow
#

this is anonymous chat for developers yes, you want our support team if you want to raise a systemic issue. But really all we can tell you(and all I would tell you if you posted the examples) is we looked, and the bank returned a decline code indicating 3D Secure was required on the $0 validation charges involved, that's really all we know directly.

#

in theory we could look to see if there are trends across certain banks or recently and look into it/escalate it internally but that's well beyond the scope of a chat on Discord

#

but like I've seen this before with other accounts and ultimately our recommendation is to integrate in our recommended ways(using SetupIntents when saving cards) , since ultimately this all up to banks and how they are interpreting the regulations about allowing merchants to save card details

gentle grotto
#

Just so I understand, what should happen in the case where we update a source for a customer, with a card requiring 3DS? You mentioned yesterday that this "shouldn't" fail, yet sometimes does, is that correct?

bright sparrow
gentle grotto
#

I'm still not quite sure on the topic of setup_future_usage:"off_session" . My understanding from yesterday is that we should be setting this for customer's outside of India, but that it won't help for our Indian customer's since they need to be "on session" - is that correct?

I'm just confused because those docs specifically mention that it shouldn't be set, so I wanted to check this we can safely make this change without impacting our customers in India.

bright sparrow
#

so there's no "should" and I don't know what the regulations imply(and ultimately it doesn't matter what I or Stripe think since the bank's decision is final and they hold all the cards here), but I'd fully expect some banks to want to force 3D Secure on these

#

those docs are aimed at our merchants with accounts in India

#

also don't mix up setup_future_usage=off_session and off_session=true, they are different parameters.

gentle grotto
#

Also to confirm my understanding on PaymentIntents: when our customer's in India experience a payment failure on a recurring invoice, , if we then bring them "on session" to update their payment details and we update the PaymentIntent associated already using confirm (see here => https://stripe.com/docs/api/payment_intents/create) - can we then expect the next payment to be successful?

bright sparrow
#

I think so but I don't really know, India is quite unique

#

but you are doing the right thing really in that case so there's nothing else you could do

gentle grotto
#

One more question 😅 When a validation charge fails due to 3DS, how come there is no PaymentIntent associated? If there were, this would allow us to us confirm on the intent to pass the 3DS checks.

bright sparrow
#

because it's just how it works. the validation is an internal object and is not part of the API

#

can't be anyway since we can't just change what the old attach API method does and returns without breaking backwards compatibility

#

this was all designed in 2018/2019 and the design decisions were that merchants need to update their integrations explicitly for SCA-ready flows(hence all the outreach we did back then), so this is all a fait accompli at this point. Our understanding has evolved over time and today, I would consider it dangerous to ever use those direct attach APIs and they're not part of documented flows