06.02 · Concept · Free
3DS, SCA & the Soft Decline You Must Escalate
Explain when strong customer authentication is required and when it is exempt, and recover a transaction the issuer soft-declined instead of losing it.
Curated for this lesson
Failure, Fraud & Disputes
Ask me anything about SCA
Directly targets SCA from a payments provider, at a suitable concept-lesson length for engineers.
3DS is the card-payment route for Strong Customer Authentication when an issuer wants extra proof from the customer. Exemptions can reduce checkout friction, but they are only requests. If an issuer returns an authentication-related soft decline, the payment flow should continue through 3DS rather than fail immediately.
What this lesson answers
- when is SCA required for card payments
- how do 3DS exemptions work in checkout
- what to do with SCA soft declines
Notes
Strong Customer Authentication is the European payment rule that says many online card payments need two independent checks, such as something the customer knows, has, or is. In card payments, 3D Secure is the common mechanism used to perform that authentication: the merchant or payment provider asks the issuer whether authentication is needed, the issuer may challenge the customer, and the authentication result is sent along with the authorization request.
Not every transaction must be challenged. Some payments are out of scope, such as merchant-initiated transactions under the right setup, and some are in scope but may be exempt, such as low-risk transactions, low-value payments, trusted beneficiaries, or certain recurring patterns. The important engineering mental model is that exemption is a request, not a guarantee: the issuer can accept it, approve without challenge, challenge the customer, or decline.
A soft decline is not the same as a final failed payment. It usually means the issuer is saying, “I might approve this, but not without stronger authentication.” The common mistake is treating every decline code as terminal and showing the customer a generic failure. For an SCA-related soft decline, the recovery path is to retry or resume the payment through 3DS so the issuer can authenticate the cardholder.
After this lesson, the student should be able to design checkout logic that distinguishes hard declines from authentication-required soft declines, requests exemptions where appropriate, and escalates to 3DS when required. They should also understand that the goal is not to avoid SCA at all costs, but to minimize unnecessary friction while preserving a reliable recovery path when the issuer demands authentication.
Common questions
- What is the difference between SCA and 3DS?
- SCA is the regulatory requirement for stronger customer verification on many European online payments. 3DS is the card-network authentication flow commonly used to satisfy that requirement. In practice, your checkout asks for authentication through 3DS when the transaction needs it or when the issuer will not approve without it.
- Are SCA exemptions guaranteed to be accepted?
- No. An exemption is a request sent with the payment, not a right to skip authentication. The issuer decides whether to approve without a challenge, ask for customer authentication, or refuse the transaction. Checkout logic should therefore handle both the frictionless case and the escalation path.
- How should a soft decline be handled?
- Treat an SCA-related soft decline as recoverable. It usually means the issuer may approve after stronger customer authentication. Instead of showing a final failure, route the customer through 3DS or resume the payment with authentication data, then submit the authorisation again.
Short definition: what is 3DS, SCA & the Soft Decline You Must Escalate?