#bennyvdhoogen-sca

1 messages · Page 1 of 1 (latest)

humble karma
#

Hey! Whilst SCA is now enforced, it is evaluated on a per transaction basis with many factors influencing whether or not an auth flow is required. It's not a blanket requirement for every payment (and there are exemptions)

#

I should stress that it's ultimately the bank/issuer the determines whether the payment requires authentication, not us. We just provide the APIs to facilitate it

agile arch
#

Thanks a lot! I'll look into the exemptions, wasn't aware of those. But am I correct in saying that as long as we use PaymentIntents we shouldn't have to worry about being SCA compliant?

rocky badger
#

PaymentIntents are a state machine for being able process a payment and handle any additional steps like 3D Secure authentication that are required during that process, so using them is what makes you SCA compliant(being able to handle payments that require authentication) yes

agile arch
#

Great!

#

Reading into those exemptions now. Regarding recurring payments: we're solely using Subscriptions (using the setup_future_usage param) to charge our customers. From what I understand there are SCA exemptions rules for recurring payments so a customer wouldn't have to re-authorize a payment after already authorising the initial payment. However, I read that we should not rely on those exemptions always being there. Do I understand correctly that it could be possible that 3DS kicks in for a certain customer even after a couple succesful charges intiatied by a Subscription?

#

And if so, how could we test such a situation?

rocky badger
agile arch
#

Ah alright, so that works for following off-sessions payments as well?

rocky badger