Quick summary
3D Secure is the protocol your payment gateway uses to authenticate online card payments, and Strong Customer Authentication (SCA) is the PSD2 rule it satisfies. Phone (MOTO) payments are exempt from SCA — but the exemption isn't a free pass, because PCI DSS and fraud controls still apply in full.
Last updated: 10 July 2026
If you run a contact centre that takes card payments, you've almost certainly hit the alphabet soup: 3D Secure, 3DS2, SCA, PSD2. The questions underneath are simpler than the acronyms suggest. What is this authentication step actually doing? When am I legally required to use it? And — the one that matters most if your agents take card details over the phone — does any of it even apply to my calls?
The short answer is that 3D Secure and Strong Customer Authentication govern online card payments, not telephone ones. But "they don't apply to phone payments" is only half the story, and the half that gets contact centres into trouble is the part nobody explains. This guide walks through what both terms mean, how they relate to each other, where the rules bite, and what you should actually do across the channels you run.
What is 3D Secure?#
3D Secure is an authentication protocol for online card payments. When you buy something online and your bank bounces you to a one-time passcode or a prompt inside your banking app before the payment goes through, that's 3D Secure doing its job. The card schemes brand it differently — Visa Secure, Mastercard Identity Check — but underneath it's the same EMVCo standard.
The "3 domains" in the name are the three parties the protocol connects: the merchant's bank (the acquirer), the cardholder's bank (the issuer), and the scheme infrastructure in the middle that lets them talk. The point of the exchange is to let the issuing bank confirm that the person entering the card details is the legitimate cardholder, before the transaction is authorised.
The original version, 3DS1, was clunky. It threw a password challenge at almost every transaction, added friction, and drove cart abandonment. The current version, EMV 3DS — usually called 3DS2 — was built to fix that. It passes far more information to the issuer (the protocol supports well over 100 data elements, against a handful in the first version), which lets the bank make a smarter, risk-based decision about whether to wave a payment through or stop and ask for proof. We'll come back to how that works in a moment.
For a contact centre, the practical thing to understand is that 3D Secure lives in the online checkout. It's a browser-and-app mechanism, delivered through your payment gateway. It was never designed for a card number being read out down a phone line.
What is Strong Customer Authentication?#
Strong Customer Authentication, or SCA, is the rule. 3D Secure is one way to satisfy it.
SCA comes from PSD2, the EU's second Payment Services Directive, which the UK retained after Brexit and which the FCA now enforces here. It requires payment service providers to authenticate a payer using at least two independent factors drawn from three categories: knowledge, possession and inherence.
Knowledge is something only the user knows — a password, a PIN, the answer to a security question. Possession is something only the user has — a phone, a card reader, a registered banking app. Inherence is something the user is — a fingerprint, a face scan, a voiceprint. The two factors have to come from different categories, and they have to be independent, meaning a breach of one can't compromise the other. A password plus a security question doesn't count, because they're both knowledge. A password plus a code sent to your phone does, because one is knowledge and the other is possession.
The reason any of this exists is fraud reduction. Card-not-present fraud — where a criminal uses stolen card details without the physical card — is the dominant fraud category in remote commerce, and a single static factor like a card number plus expiry date is trivially easy to steal and reuse. Forcing a second, independent factor at the point of payment makes stolen card data far less useful on its own.
How 3D Secure delivers SCA: frictionless versus challenge#
Here's where 3DS2 earns its keep. Instead of challenging every customer, it runs a real-time risk assessment first, and only interrupts the ones that look risky.
When a customer pays online, the merchant's system sends the issuing bank a rich bundle of data — the transaction details, the device being used, its location and IP, the cardholder's history with that merchant, and dozens of other signals. The bank scores all of it in real time. If the transaction looks legitimate and low-risk, the bank approves it without bothering the customer at all. That's the frictionless flow, and for the customer it feels like the payment just worked.
If the transaction looks risky, or the value crosses a threshold where SCA is mandatory, the bank triggers the challenge flow. Now the customer has to actively prove who they are — typically by entering a one-time passcode, or by approving the payment inside their mobile banking app, which is known as out-of-band authentication. Only after they pass does the payment complete.
There's a second benefit beyond fraud prevention that matters commercially: liability shift. When a transaction is authenticated through 3D Secure and later turns out to be fraudulent, liability for the chargeback generally moves from the merchant to the issuing bank. For a business carrying CNP fraud risk, that shift is often reason enough to use 3DS even where it isn't strictly mandated.
Does SCA apply to phone payments? The MOTO exemption#
This is the section that matters if your agents take card details over the phone, so it's worth being precise.
Card payments taken over the phone are Mail Order/Telephone Order transactions — MOTO. And MOTO payments are exempt from Strong Customer Authentication. The reason is structural rather than a special carve-out: PSD2's SCA requirement applies to electronic remote payments, and a card number given verbally during a live phone conversation isn't an electronic remote payment in the sense the rules define. The cardholder isn't authenticating through a browser or an app, so there's no electronic channel for 3D Secure to operate on. The requirement simply doesn't reach that transaction.
So if a customer calls your contact centre and reads their card details to an agent, you don't apply 3D Secure, and you don't need to. That's a genuine operational advantage of the phone channel, and it's worth understanding rather than working around.
But — and this is the part that catches people out — the exemption is narrow, and it is not a free pass on everything else. Three things stay firmly in scope.
First, PCI DSS still applies in full. Being exempt from SCA does nothing for your obligations to protect cardholder data. If anything, phone payments raise the stakes, because a card number spoken aloud can be overheard by an agent, captured in a call recording, or exposed across your wider environment. PCI DSS v4.0.1, mandatory since March 2025, includes specific provisions for telephone payment environments precisely because of this — we've covered the PCI rules for card payments over the phone separately.
Second, fraud controls still apply. The SCA exemption removes a regulatory authentication step; it doesn't remove the fraud risk. Acquirers frequently impose their own requirements on MOTO traffic, and a phone channel with no fraud screening is an obvious target.
Third, the exemption only covers the phone leg. The moment a payment moves to an online channel — you email the customer a payment link, or send them to a hosted page — you're back in electronic-remote-payment territory, and SCA applies again.
This is exactly the territory Paytia was built for. Paytia sits in the middle of a live call and captures card details using DTMF masking, so the agent never hears or sees the number — the customer types it on their phone keypad and the tones are masked. The card data stays out of the agent leg, out of the call recording, and out of your environment, which is what cuts PCI-DSS scope by up to 96% for contact-centre operations. You get the SCA exemption that comes with the phone channel and the data protection that PCI DSS demands, without making your agents part of the cardholder data environment. Paytia has held PCI-DSS Level 1 — the highest tier — through every revision of the standard since the company was founded in 2016.
Take card payments over the phone? Book a 15-minute demo — we'll show you how an agent takes a payment without ever hearing a card number.
3D Secure and SCA for card-not-present fraud#
Most contact centres don't live purely on the phone. You'll have an online checkout, payment links, maybe a self-service portal — and every one of those is a card-not-present channel where 3D Secure does apply.
It's worth using it even where a specific exemption might let you skip it. CNP fraud is the channel where stolen card data gets monetised, and the EMV 3DS protocol exists specifically to help issuers catch unauthorised e-commerce transactions quickly and accurately. In practice this is a payment gateway question: a gateway with 3DS2 built in handles the risk assessment and any challenge automatically, so you're not integrating the protocol yourself. The frictionless flow means you can run that protection on the bulk of your legitimate traffic without adding a visible step for genuine customers, while the challenge flow catches the transactions that warrant a second look. Add the liability shift on top, and 3DS is usually the right default for any online card payment, not just the ones where the rules force it.
The cleaner way to think about it across your operation is by channel. Phone payments are MOTO, SCA-exempt, and protected by keeping card data out of the agent environment. Online payments are CNP, subject to SCA, and protected by 3D Secure. Both need PCI DSS. If you map your channels that way, the acronyms stop being confusing and start being a checklist.
What contact centres should actually do#
Pulling it together, here's the practical position.
Start by mapping every channel you take payments on and labelling each one MOTO or CNP. Live agent calls and IVR phone payments are MOTO and exempt from SCA. Online checkouts, payment links and hosted pages are CNP and subject to it. That single distinction tells you where 3D Secure belongs and where it doesn't.
On the phone channel, don't treat the SCA exemption as the finish line. Keep card data out of your agents' hands entirely — DTMF masking is the established way to do this — so a spoken card number never enters your environment in the first place. That's what keeps you inside the exemption and compliant with PCI DSS, rather than just one or the other. Our overview of taking card payments over the phone covers how the descope works in practice.
On the online channels, implement 3D Secure properly and lean on the frictionless flow so you're not punishing legitimate customers with needless challenges. Treat the liability shift as a feature, not an afterthought.
And keep PCI DSS v4.0.1 running underneath all of it, because no SCA exemption touches your obligation to protect cardholder data. Customers who've made this shift describe the outcome in the same terms our own do — peace of mind that card information is handled safely, and a setup their agents find easy to use. That's the goal: each channel handled the right way, with the compliance burden engineered down rather than bolted on.
Troubleshooting: why 3D Secure authentication fails#
A quick practical note, since "3D Secure authentication failed" is one of the most common things people search after a declined online payment. Authentication failures usually come down to one of a few causes: the card isn't enrolled in 3D Secure with its issuing bank, the issuer's system timed out or was temporarily unavailable, the customer entered the wrong one-time passcode or let it expire, the card is of a type or region the gateway doesn't support for 3DS, or a browser or app issue interrupted the challenge. The fix is almost always on the cardholder-and-issuer side — retrying, checking the card is enrolled, or contacting the bank — rather than something the merchant can resolve directly. If failures spike across many customers at once, that points to a gateway or configuration problem worth raising with your provider.
Frequently asked questions#
Does Strong Customer Authentication apply to phone payments?
No. Card payments taken over the phone are Mail Order/Telephone Order (MOTO) transactions, which fall outside PSD2's definition of electronic remote payments and are therefore exempt from SCA. The exemption doesn't remove your obligation to comply with PCI DSS or to run fraud controls on that traffic.
What is the difference between 3D Secure and Strong Customer Authentication?
SCA is the regulatory requirement, under PSD2, to authenticate a payer using two independent factors. 3D Secure is the technical protocol the card schemes use to deliver SCA for online card-not-present payments. In short, 3DS is the mechanism; SCA is the rule it satisfies.
What are the three factors of Strong Customer Authentication?
Knowledge (something only the user knows, like a password or PIN), possession (something only the user has, like a phone or banking app) and inherence (something the user is, like a fingerprint or face scan). SCA requires at least two factors from different categories, and the factors must be independent of one another.
What is a 3D secure payment gateway?
A payment gateway with 3D Secure support built in. When a customer pays through it, the gateway handles the 3DS exchange with the issuing bank automatically — running the risk assessment, triggering a challenge if one is needed, and passing the authentication result through with the transaction. Most modern gateways support 3DS2 as standard; the setting usually just needs switching on.
Is 3D Secure mandatory?
For online card-not-present payments within scope of PSD2/SCA, authentication is required, and 3D Secure is the standard way to provide it, subject to the available exemptions. For phone (MOTO) payments it isn't required at all. Many merchants choose to use 3DS on online payments even where an exemption would apply, because of the fraud reduction and the chargeback liability shift it provides.
Do MOTO phone payments still need to be PCI compliant?
Yes. The SCA exemption for MOTO has no bearing on PCI DSS. Any business taking card payments over the phone must still protect cardholder data and meet PCI DSS requirements — which is exactly why keeping card numbers out of the agent environment matters.
Where this leaves you#
3D Secure and SCA aren't as complicated as the acronyms make them look once you split your payments by channel: online is CNP and needs authentication, phone is MOTO and is exempt, and everything needs PCI DSS. If most of your card payments come in over the phone, that exemption is an advantage worth using properly — see how Paytia secures live agent calls without making your team part of the cardholder data environment on our telephone payments page.
Related reading#
- 3DS2 Chargebacks: Who Pays When Fraud Happens?
- Card Not Present Transactions: Risks and How to Cut Fraud
- Card Payments Over the Phone: PCI Rules 2026
Want to see the phone side working? Book a 15-minute demo — we'll show you a live agent payment with the card data kept out of the call.
