What is Strong Customer Authentication?

What SCA Is

Strong Customer Authentication — SCA — is the rule under the EU's revised Payment Services Directive (PSD2) that says an electronic payment has to be verified using at least two independent authentication factors. The UK kept the same rule after Brexit. The point is to make it much harder for someone with stolen card details to actually use them, because the card number and expiry on their own no longer get you through checkout.

In practical terms, the customer has to prove who they are using two out of three categories of evidence. The days of "long card number plus expiry plus CVV" being enough are long gone for most online transactions.

The Three Factors

SCA wants two of these three:

• Something the customer knows — a password, a PIN, a security question answer. The traditional one.
• Something the customer has — a phone, a hardware token, a smart card. Usually verified by a one-time code or a banking-app push notification.
• Something the customer is — fingerprint, face, voice. Biometrics.

The two factors have to come from different categories. Two passwords doesn't count, because they're both "something you know." The whole idea is that if a fraudster steals one factor, they still can't get through without one from a different category. Steal a password and you don't have the phone; steal the phone and you don't have the fingerprint.

When SCA Applies (And When It Doesn't)

SCA applies to customer-initiated electronic payments in the UK and EEA. That covers most online card payments, bank transfers, and a lot of contactless. There are exemptions, though, and they matter:

• Low-value transactions — payments under €30 (£30 in the UK) can be exempt, but the exemption resets after a number of consecutive low-value transactions or a cumulative amount.
• Recurring payments — once the first payment in a subscription is authenticated, the following same-amount, same-merchant payments can skip SCA.
• Trusted beneficiaries — customers can whitelist a merchant with their bank so future payments to that merchant skip SCA.
• Transaction risk analysis (TRA) — payment providers with low fraud rates can apply real-time risk scoring and exempt low-risk transactions. Their fraud rate has to stay under a threshold or they lose the exemption.
• Merchant-initiated transactions (MIT) — utility bill collections, account top-ups initiated by the merchant rather than the customer, fall outside SCA entirely.

Why It Matters for the Business

If you sell to UK or European customers online, SCA has already changed your checkout. Every additional authentication step is friction, and friction is where carts get abandoned. The job is to satisfy the rule without driving the customer away — which means working with a payment provider that supports 3D Secure 2 (3DS2), the modern authentication flow designed to feel less like an obstacle course than the original 3D Secure ever did.

Non-compliance isn't just a regulatory risk either. A transaction that should have been SCA-authenticated but wasn't can be declined by the issuing bank, which means lost revenue in real time. Get this wrong at scale and you lose serious money before anyone in compliance notices.

SCA and Telephone Payments

Phone payments are an awkward fit for SCA. A traditional MOTO (Mail Order / Telephone Order) call — customer reads card to agent — only has one channel: the voice call itself. You can't easily layer a second factor onto that.

The good news is that PSD2 technically exempts MOTO transactions from SCA, because the rule targets electronic payments and a MOTO is treated as card-not-present in a different category. Whether your specific phone payment counts as MOTO depends on how the transaction is processed and who initiates it, so it's worth checking with your acquirer.

Even with the MOTO exemption, plenty of merchants are layering SCA onto phone payments anyway, purely as a fraud control. Modern phone payment platforms can fire a 3DS2 authentication mid-call: the customer gets an SMS or email link, completes the authentication on their own phone (or in their banking app), and the agent stays on the line throughout. You get the SCA assurance without making the customer hang up and start again in a different channel.

Practical Considerations

• Sit down with your payment provider and work out which of your transactions need SCA, which qualify for an exemption, and how the exemption is requested in the API call. Default-on SCA is the safest bet if you're unsure.
• Get to 3DS2 if you're not already. The older 3DS1 flow is a much worse experience for customers and a higher abandonment rate.
• Watch your decline rate after every change. If declines spike, the bank's risk engine is probably rejecting your authentication flow rather than the cards themselves.
• For phone payments, know whether your processor classes the transaction as MOTO. The exemption usually applies, but the rules around agent-assisted versus self-service IVR can shift the answer.
• If you're chasing TRA exemptions for low-risk online transactions, your provider's fraud rate has to stay under the regulatory threshold. Build a quarterly review into the process so you don't find out you've lost the exemption when transactions start declining.