#Shammah Chancellor - 3D Secure in the US
1 messages · Page 1 of 1 (latest)
Hello! Generally speaking no, but it's ultimately up to the individual card issuers. I don't think there's anything preventing them from enforcing it if they wanted to, although it would be quite unusual to see that in the US.
Hmm.. Okay. Is there a radar setting that could be initiating it's use on our end?
Are you sure you don't have a Radar rule or something that required 3D Secure on a card that only supports it even though it wasn't required?
heh
Yes. 🙂
Okay. Maybe someone fiddled with our configuration. This issue suddenly popped up.
Thanks
Can you possibly look at this charge and lmk if there's something we can do without implementing 3DS? ch_3KS0rdAN9UGzw70g0DvrUPD9
Taking a look, but out of curiosity why do you want to avoid adding support for 3D Secure?
We don't, I'm just swamped with other "emergencies"
We're still on the old charges API due to needing ACH support (IDK if that's supported yet in paymentintents). It looks like 3DS flows aren't supported w/ the charges API?
Correct, Payment Intents are required for 3D Secure support. You can have card payments running on Payment Intents/newer APIs and still use ACH with Sources alongside. Payment Intent/Payment Method support for ACH is being worked on now, but we don't have a public release date yet.
Thanks. We will be doing that as soon as we can, just limited bandwidth.
Gotcha. Give me a few minutes to investigate this Charge...
Looks like this is newish behavior by the card issuer. Looks like they're prompting for 3D Secure when a transaction looks sufficiently risky to them regardless of where that transaction takes place (meaning even in the US). There are really only two things you can do: ask the customer to ask their card issuer about why they blocked the charge and if they could allow the next attempt to succeed, and/or upgrade your integration to support authentication challenges.
Great, thank you!