← Payment Reference GuidesAuthentication Reference

Strong Customer Authentication (SCA)

SCA is the PSD2 rule that an electronic payment, or online access to a payment account, must be authenticated with two independent factors — and, for remote payments, bound to the exact amount and payee. This guide covers the whole rule set across channels: the factors and dynamic linking, what is out of scope and every exemption with its thresholds, how SCA runs for cards online and in store and for online and open banking, the UK regime, what PSD3 / PSR change, and similar mandates elsewhere.

Shipping SCA: a checklist

If you are a merchant or PSP

  • Run EMV 3DS 2.2 or later, browser and app channels, with full device and cardholder data — data quality drives frictionless rates.
  • Decide an exemption strategy per transaction: low value, acquirer TRA, trusted beneficiary, or plain 3DS — and route to 3DS or straight to authorization accordingly.
  • Handle soft declines (Visa 1A, Mastercard 65) automatically: challenge with indicator 04 while the shopper is still there, then resubmit.
  • Set up MIT agreements with an authenticated CIT; store and send the network transaction ID; flag every MIT with the right reason.
  • Flag MOTO, MIT, one-leg-out and corporate cards correctly — never as a way to dodge SCA.
  • Monitor approval rate, challenge rate and soft-decline rate per issuer country.

If you are an issuer or run the ACS

  • Offer at least two independent SCA methods, one not dependent on a smartphone.
  • Show amount and merchant in every challenge, and bind the CAVV/AAV to them.
  • Keep low-value and contactless counters consistent across 3DS, authorization and the chip.
  • Compute TRA fraud rates quarterly per Art. 19 and stop using a band when you breach it twice.
  • Recognise wallet CDCVM, delegated-authentication indicators and 3RI requests.
  • Lock credentials after at most five failed attempts, without revealing which element failed.

If you are a bank (ASPSP)

  • Apply SCA to login, payments and every sensitive action (payees, limits, devices, contact details).
  • Implement dynamic linking end to end: what the app displays is what the server verifies.
  • Apply the mandatory Art. 10a exemption for AISP access, with 180-day renewal.
  • Support redirect (app-to-app) and decoupled SCA on the open-banking interface with the same methods as your own channels.
  • Device enrolment for the banking app is itself an SCA event; bind keys in the secure element / TEE.

Common mistakes

  • Treating a 3DS frictionless result as "SCA done" for MIT setup — frictionless means an exemption, so the issuer may soft-decline the later MITs.
  • Flagging customer-present checkouts as MIT or MOTO.
  • Retrying a soft decline without authentication, or downgrading it to a non-3DS attempt.
  • Assuming the merchant can see the low-value counters — only the issuer knows how many exempt payments came since the last SCA.
  • An SMS OTP that does not state amount and payee.
  • Using the card number or CVV as one of the two factors.
  • Changing the amount after authentication (upsell, shipping) without re-authenticating or an MIT.
Texts you will quote in design reviews. PSD2 (Directive (EU) 2015/2366) Articles 4(30), 74 and 97; Commission Delegated Regulation (EU) 2018/389 (SCA-RTS) and its amendment 2022/2360; EBA Opinion on the elements of SCA (EBA-Op-2019-06) and the EBA Q&A on PSD2; FCA SCA-RTS and the Payment Services Approach Document for the UK; EMV 3-D Secure Protocol and Core Functions Specification 2.2 / 2.3.

Related tools: 3DS Message tool · CAVV calculator · Response codes · Payment authorization flow · Verification of Payee

🧩 Check yourself

Can you authenticate and authorize an online payment in the right order?

Expert · shortest route 12 hops · hints included
Put it into practice

Next steps

Tool3DS2 Message Builder & DecoderSketch EMV 3DS (3DS2) AReqs and decode AReq, ARes, CReq/CRes (incl. base64url creq/cres), RReq and Erro messages — transStatus, ECI, reason and error codes explained field by field.Open the tool ToolResponse Code ReferenceSearchable ISO 8583 DE 39 response codes with Visa and Mastercard meanings — Visa decline categories and reattempt limits, plus Mastercard Merchant Advice Codes.Open the tool ToolPayment Authorization FlowStep through a complete card payment as an animated sequence diagram — authorization, clearing, and settlement — for both card-present and e-commerce (3-D Secure) flows.Open the tool Flow3-D Secure frictionless and challenge flowsSee the animated message flow, step by step, between every party involved.Watch the flow
Keep reading

Related articles

Authentication3D Secure (EMV 3DS)Authentication flows, message types, ECI values, SCA exemptionsRead article Open BankingOpen Banking & PSD2AISP/PISP roles, consent & SCA flows, FAPI security, UK / Berlin Group / STET, PSD3 & PSRRead article IdentityEUDI Wallet & PaymentseIDAS 2.0 deadlines, the SD-JWT VC / mdoc / OID4VP stack, wallet-based PSD2 SCARead article Card RailsPayment TokenizationFPAN→DPAN lifecycle, VTS vs MDES, TAVV cryptogramsRead article