3DS, SCA & the Soft Decline You Must Escalate
3DS is the card-network authentication flow commonly used to satisfy Strong Customer Authentication for online card payments. It lets the issuer verify the cardholder before authorisation, or demand that verification after a soft decline, where the original payment was not finally rejected but needs stronger authentication to continue.
The problem is that online card payments sit between fraud prevention, regulation, and checkout conversion. In many European card flows, the merchant cannot simply collect card details and ask for authorisation as if authentication were optional. At the same time, challenging every buyer is unnecessary friction. Engineers need checkout logic that can tell when authentication is required, when an exemption can be requested, and when an issuer has refused the first attempt only because authentication was missing.
Mechanically, 3DS inserts an authentication step before, or during recovery from, authorisation. The merchant or payment provider sends transaction and browser or app context into the 3DS flow. The issuer decides whether it can authenticate silently, needs to challenge the customer, or will not proceed. The resulting authentication data is then attached to the card authorisation request so the issuer can approve with evidence that the cardholder was checked.
The trade-off is control. Exemptions such as low-risk, low-value, trusted beneficiary, or correctly set up merchant-initiated transactions can reduce friction, but they are requests rather than entitlements. The issuer may accept the exemption, ignore it and challenge, or decline. A common misunderstanding is that soft declines are ordinary payment failures. For SCA, the honest interpretation is often: try again with authentication, not give up.
Engineers meet this in payment intent state machines, decline-code handling, and checkout recovery. Your integration should separate hard declines from authentication-required soft declines, preserve enough state to resume the payment, and route the customer into 3DS when the issuer asks for it. The practical goal is not to bypass SCA, but to request sensible exemptions while keeping a reliable escalation path when authentication becomes mandatory.
Common questions
- Is 3DS the same thing as SCA?
- No. SCA is the regulatory requirement for strong customer authentication in many online payment situations. 3DS is the card-payment protocol commonly used to perform that authentication. Think of SCA as the rule and 3DS as one mechanism that lets the issuer verify the cardholder and return authentication evidence for authorisation.
- When can a payment avoid a customer challenge?
- It depends on scope, transaction type, issuer policy, and risk. Some payments are outside SCA when set up correctly, such as certain merchant-initiated payments. Others are in scope but may request exemptions, such as low-risk or low-value transactions. The issuer still decides whether to accept the exemption or require authentication.
- What should checkout do after an SCA soft decline?
- Do not treat it like a final card failure. An SCA soft decline usually means the issuer may approve the payment, but only after stronger authentication. Your flow should retry or resume the transaction through 3DS, collect the authentication result, and then submit the authorisation again with that evidence attached.