Strong Customer Authentication
What Is Strong Customer Authentication? Definition and How It Works
Definition
Strong Customer Authentication (SCA) is a European regulatory requirement under PSD2 that mandates electronic payments be verified using at least two independent authentication factors from the categories of knowledge, possession, and inherence before being authorised.
How it works
SCA requires that authentication draws from at least two of three factor categories. Knowledge is something only the user knows: a password, PIN, or passphrase. Possession is something only the user has: a mobile device, a hardware token, or a card reader. Inherence is something the user is: a fingerprint, facial recognition, or behavioural biometric.
The two factors must be independent, a compromise of one must not compromise the other. A one-time passcode sent to the user's mobile phone satisfies possession (the device) and implicitly knowledge (the code), and this combination is the most widely used SCA implementation in card payments, delivered through the 3DS 2.x challenge flow.
SCA applies to customer-initiated electronic payments within the European Economic Area where both the payer's payment service provider and the payee's payment service provider are within the EEA. This is called the two-legs-in condition: if either the issuer or acquirer is outside the EEA, SCA is not mandated by PSD2, though issuers may still apply their own authentication requirements.
SCA has defined exemption categories that allow specific transaction types to proceed without two-factor authentication: low-value transactions under 鈧30, transactions covered by transaction risk analysis (TRA), recurring transactions with fixed amounts to the same payee, transactions to trusted beneficiaries whitelisted by the cardholder, and merchant-initiated transactions on previously authenticated stored credentials.
Why it matters
SCA non-compliance causes hard declines: issuers in EEA markets must decline transactions that require SCA but have not been authenticated. Unlike fraud-related declines, these are architectural; they cannot be recovered without implementing proper 3DS authentication or a valid exemption.
Exemption strategy affects conversion: blanket SCA on every transaction adds unnecessary challenge friction. A well-designed exemption strategy, applying TRA exemptions to low-risk transactions and routing eligible recurring transactions as MITs, reduces challenge rates and improves conversion while maintaining compliance.
SCA scope is determined by both legs of the transaction: one-leg-out transactions (where the issuer or acquirer is outside the EEA) are not mandated for SCA. Merchants with mixed domestic and international customer bases need routing and exemption logic that correctly identifies which transactions are in scope.
3DS 2.x is the practical implementation vehicle: SCA is a regulatory requirement; 3DS 2.x is the technical mechanism through which card payments meet it. Merchants without 3DS 2.x integration in EEA markets are structurally non-compliant.
With PXP
PXP's 3DS 2.x integration covers the full SCA authentication flow including exemption request logic. Merchants configure exemption thresholds and SCA scope rules through PXP's dashboard. PXP handles the technical SCA compliance layer, returning compliant authentication results to the acquirer for authorisation.
Frequently asked questions
What are the three SCA authentication factor categories?
The three categories are: knowledge (something only the user knows, password, PIN, passphrase); possession (something only the user has, mobile device, hardware token, card reader); and inherence (something the user is, fingerprint, facial recognition, behavioural biometrics). SCA requires at least two factors from different categories for each qualifying transaction.
Which transactions are exempt from SCA under PSD2?
PSD2 SCA exemptions include: transactions under 鈧30 (low-value exemption, subject to cumulative limits); transactions where the acquirer or issuer applies transaction risk analysis (TRA) within defined fraud rate thresholds; recurring transactions with fixed amounts to the same payee after an initial authenticated setup; transactions to payees on the cardholder's trusted beneficiary list; and merchant-initiated transactions on stored credentials from a prior authenticated session.
Does SCA apply to all online card transactions in Europe?
SCA applies to customer-initiated card-not-present transactions where both the payer's PSP and the payee's PSP are within the EEA (the two-legs-in rule). Transactions where the issuer or acquirer is outside the EEA are one-leg-out and not mandated for SCA under PSD2, though issuers may still apply their own authentication requirements. Merchant-initiated transactions (recurring charges on stored credentials without cardholder initiation) are also out of scope for SCA.
What is the liability shift under SCA?
When a transaction is authenticated under SCA (via 3DS) and later disputed as fraud, liability shifts to the issuer, not the merchant. When a merchant applies an SCA exemption and the transaction is later disputed, liability typically remains with the merchant. Merchants should weigh the conversion benefit of exemptions against the increased fraud liability, particularly for higher-value transaction segments.
Revolutionize your business with PXP
Take complete control of your commerce and payments with one platform.
Get Started