What is 3-D Secure? 3-D Secure (3DS) is a cardholder authentication protocol for online transactions, managed by EMVCo. Before a shop sends a transaction for authorisation, three cooperating systems – the 3DS Server on the shop’s side, the Directory Server (DS) on the payment network’s side, and the ACS on the issuing bank’s side – exchange data and decide whether and how to confirm the buyer’s identity.
Canonical definition: EMV 3-D Secure (EMV 3DS) is a cardholder authentication protocol managed by EMVCo for card-not-present transactions, based on the exchange of messages between the shop, payment network and issuer domains.
This article explains the protocol on two levels: for the layperson who wants to understand what happens after clicking “pay”, and for the organisation considering providing 3DS services to other companies.
3-D Secure – key takeaways:
- The name “3-D” comes from three security domains: the acquirer domain (the shop and 3DS Server), the interoperability domain (the payment network and DS) and the issuer domain (the bank and ACS).
- The current specification version is EMV 3DS 2.3.1.1 (2023), which replaced the 2.3.1.0 release from 2022; EMVCo recommends versions 2.2 or higher for full SCA support (EMVCo).
- Most transactions take the frictionless path: the issuer authenticates the buyer through risk analysis of over a hundred data attributes, with no question to the customer at all.
- The DS (Directory Server) is a technical role of the payment networks – not to be confused with PCI DSS, the card data security standard with an entirely different scope.
- ACS, DS, 3DS Server and 3DS SDK products go through EMVCo’s formal approval process (pre-compliance testing on a recognised platform, a laboratory, an ICS, compliance testing), and the environments they run in fall under the PCI 3DS Core Security Standard v1.0.
- Patronusec, an accredited QSA, supports 3DS service providers with PCI 3DS certification – from role classification to environment readiness for assessment.
Table of Contents
What is 3-D Secure and where does the “three domains” name come from?
3-D Secure adds a step to online card payments that a physical terminal does not need: confirming that the person paying really is the cardholder. The name comes from the three domains in which the protocol’s participants operate: the acquirer domain, the interoperability domain and the issuer domain.
An analogy for the layperson: a 3DS transaction resembles an airport check. The shop (the airline) presents the passenger, the payment network (the airport) directs them to the right gate, and the issuing bank (passport control) decides – most people pass without being stopped, and a select few are asked for a document. Likewise: the shop initiates authentication, the network locates the customer’s bank, and the bank assesses risk and only sometimes asks for confirmation.
The history in three sentences. The first version of the protocol (3DS 1.0) emerged in the early 2000s and relied on static passwords that customers forgot and shops lost baskets over. EMVCo took over development and published EMV 3DS 2.x – a protocol built around risk analysis and device data instead of passwords. The current specification release is 2.3.1.1 (2023), extending among other things out-of-band authentication and Secure Payment Confirmation (EMVCo).
In Europe, regulation reinforced 3DS: the PSD2 directive requires strong customer authentication (SCA) for electronic payments, and EMV 3DS is the primary protocol issuers use to meet that obligation – EMVCo recommends versions 2.2 or higher for it.
EMV 3DS inverts the logic of the protocol’s first version: instead of asking every customer for a password, it hands the issuer data about the transaction and device so it can ask only when the risk warrants it.
How does 3DS authentication proceed step by step?
3DS authentication is a message exchange that usually takes fractions of a second: the shop sends a request with transaction data, the payment network routes it to the issuing bank, and the bank responds with an outcome – either immediately (the frictionless path) or after the customer provides additional confirmation (the challenge path).
The flow in six steps:
- The customer clicks “pay” in an online shop or app.
- The shop’s 3DS Server builds an AReq (Authentication Request) message with transaction, browser or device data and sends it to the payment network.
- The network’s DS (Directory Server) recognises from the card number which bank issued it and forwards the AReq to the right ACS.
- The bank’s ACS assesses risk: it compares the transaction data against the customer’s history, device, amount and typical patterns.
- The frictionless path: low risk – the ACS returns a positive result (ARes) and the customer notices nothing. The challenge path: elevated risk or a regulatory requirement – the customer confirms identity, for example via biometrics in the bank’s app or a one-time code.
- The authentication result (including a cryptographic value attesting to how it ran) reaches the shop, which only now sends the transaction for authorisation.
The key commercial benefit: in card schemes, 3DS authentication generally comes with a shift of fraud liability from the shop to the issuer – the detailed conditions are set by each payment network’s rules.
3DS authentication precedes authorisation and is separate from it: 3DS answers “is the cardholder paying”, while authorisation answers “are there funds on the card”.
What is the 3DS Server and who operates it?
The 3DS Server is a component of the acquirer domain: the system that initiates authentication on the shop’s behalf, builds AReq messages, maintains certified connections to the payment networks’ Directory Servers, and returns the outcome to the shop. Historically this role was played by the MPI (Merchant Plug-In) component from 3DS 1.0.
In practice, few shops operate their own 3DS Server. The standard market model is a service: a payment gateway, acquirer or specialist provider operates a single 3DS Server for hundreds of merchants who integrate via an API. The shop sees one simple response (“authenticated / challenge required / declined”), while the provider handles all the protocol complexity – specification versions, message extensions, DS certificates.
For an organisation considering providing this service to other companies, the 3DS Server is the most common entry point into the 3DS market: it requires being neither a bank nor a payment network, and the customer can be any merchant or PSP. The product must, however, pass EMVCo approval (see the service-provision section below), the environment must achieve PCI 3DS certification, and the operator must register in each payment network’s programmes.
The 3DS Server is the only EMV 3DS protocol component that can be operated by a provider independent of both banks and payment networks – which is why the 3DS services market for merchants centres on it.
What is the Directory Server (DS) and why is it not PCI DSS?
The Directory Server (DS) is a component of the interoperability domain, operated by the payment networks: it determines from card number ranges which issuer serves a given card and routes authentication messages between the 3DS Server and the right ACS. It is the router and trust gatekeeper of the entire protocol.
The DS’s tasks in practice:
- maintaining a directory of card ranges and issuer participation in 3DS – 3DS Servers retrieve this data via PReq/PRes messages,
- routing AReq/ARes messages between thousands of 3DS Servers and thousands of ACSs,
- managing trust: every 3DS Server and ACS connects to the DS using certificates issued within that network’s programme,
- fallback: networks offer mechanisms to handle authentication when an issuer does not participate in 3DS or its ACS is unavailable.
Let us clear up a common naming confusion. DS (Directory Server) is a technical role in the EMV 3DS protocol. PCI DSS (Payment Card Industry Data Security Standard) is a card data security standard applying to every entity that processes card data. The abbreviations sound alike but describe entirely different things – and to top it off there is also PCI 3DS: the security standard for the environments in which ACS, DS and 3DS Server components run.
The Directory Server (DS) is a role in the EMV 3DS authentication protocol played by the payment networks, whereas PCI DSS is a card data protection standard – the similarity of the abbreviations is coincidental.
What is the ACS and what does the issuer do during authentication?
The ACS (Access Control Server) is a component of the issuer domain: the system that decides, on the bank’s behalf, whether to authenticate a transaction with no customer involvement, ask for additional confirmation, or decline. The frictionless-versus-challenge decision is made in the ACS, and the ACS conducts the challenge itself.
As input, the ACS receives in the AReq message a rich set of data about the transaction, the browser or device and the sales channel. The issuer’s risk engine matches it against what the bank knows about the customer: transaction history, typical devices, geography, limits. The analysis outcome determines the path:
- frictionless – authentication completes in the background; the customer sees no extra step,
- challenge – the ACS presents the customer with a challenge: a push notification with biometric confirmation in the bank’s app, a one-time code, or another SCA-compliant method; in Europe, the choice of methods is shaped by PSD2 and its technical standards.
Commercially, the ACS is the domain of specialist providers: most banks do not build their own ACS but buy it as a product or service from technology firms serving many issuers. This is the second realistic market-entry model for 3DS services, alongside the 3DS Server – except that here the customer is a bank, and the integration requirements (anti-fraud systems, challenge channels, the issuer’s mobile app) run considerably deeper.
Patronusec Insight: In our project experience, organisations entering the 3DS services market are most often surprised not by the EMVCo approval itself, but by the PCI 3DS environmental scope. The standard covers systems performing ACS, DS or 3DS Server functions and systems that impact them – which means the back end too: HSM management for protocol keys, admin panels, monitoring. Before you plan the product’s EMVCo approval, draw the 3DE boundaries the way an assessor will – the real cost of running the service depends on them.
What does it take to provide 3DS services to other companies?
Entering the 3DS services market requires three parallel tracks: EMVCo product approval, PCI 3DS environment certification, and registration plus testing in each payment network’s programmes. Only the full set opens commercial provision of ACS, DS or 3DS Server services.
Track one – EMVCo approval for the product (ACS, DS, 3DS Server or 3DS SDK), per EMVCo’s published process:
- registration with EMVCo and signing a contract (a registration number),
- product pre-compliance testing on an EMVCo-recognised test platform,
- review of the test report by a chosen laboratory,
- submission of the ICS (Implementation Conformance Statement) form and compliance testing,
- EMVCo review of the results and publication of the product on the approved list (a Letter of Approval).
Track two – environment security. Systems performing or supporting ACS, DS and 3DS Server functions fall under the PCI 3DS Core Security Standard v1.0, assessed by qualified 3DS assessors. The standard comprises a baseline part (Part 1) and 3DS-specific requirements (Part 2), covering among other things protecting the protocol’s cryptographic keys in HSMs. If the environment also processes card data, PCI DSS applies in parallel – and a valid PCI DSS assessment can satisfy the Part 1 baseline where the 3DE sits within the CDE.
Track three – payment network programmes: an ACS or 3DS Server operator registers in each network’s 3DS programme (obtaining, among other things, certificates for connecting to their DS) and passes their integration testing. Each network sets its own conditions.
Patronusec guides providers through the environmental track within its PCI 3DS certification service – from setting the 3DE boundary to assessment readiness.
Myth vs fact: what do people get wrong about 3-D Secure?
MYTH: The DS in the 3DS protocol is the same as PCI DSS.
FACT: The DS (Directory Server) is a routing component in the EMV 3DS protocol operated by payment networks. PCI DSS is a card data security standard. All they share is a similarity of abbreviations.
MYTH: 3DS always means an extra step and lost conversion.
FACT: The EMV 3DS 2.x protocol was designed around the frictionless path: the issuer authenticates the customer from transaction and device data, and a challenge appears only at elevated risk or under a regulatory requirement.
MYTH: 3DS authentication guarantees a transaction is not fraud.
FACT: 3DS confirms the cardholder’s identity and generally shifts fraud liability to the issuer, but it replaces neither authorisation nor anti-fraud systems – it remains one layer of protection.
MYTH: EMVCo approval alone is enough to provide 3DS services.
FACT: EMVCo approval covers the product. The operator additionally needs environment certification under PCI 3DS plus registration and testing in the payment network programmes.
MYTH: The 3DS Server is a program installed in the online shop.
FACT: The 3DS Server is a certified server-class system, usually operated by a gateway, acquirer or specialist provider for many merchants; the shop integrates with it via an API.
FAQ
Is 3-D Secure mandatory?
In the European Economic Area, strong customer authentication (SCA) is required by PSD2, and EMV 3DS is the primary protocol for delivering it for card payments – with exceptions provided in the technical standards (low-value transactions, risk analysis, and others). Outside the EEA, payment network rules and local regulation determine the requirements.
How does the frictionless path differ from the challenge?
Frictionless is background authentication: the ACS assesses risk from the AReq message data and returns a result without customer involvement. A challenge is additional identity confirmation – for example biometrics in the bank’s app or a one-time code – used at elevated risk or under a regulatory requirement.
Who operates the Directory Server?
The payment networks – each maintains its own DS for its card ranges within its 3DS programme. 3DS Servers and ACSs connect to the DS using certificates issued in those programmes. Neither the merchant nor the bank communicates with the DS directly – their certified components do.
What is liability shift in 3DS?
It is the shift of financial liability for “unauthorised transaction” fraud from the shop to the card issuer after successful 3DS authentication. The detailed conditions (transaction types, exceptions, regions) are set by each payment network’s rules, so it is worth verifying them with your acquirer.
What is PCI 3DS and who does it apply to?
The PCI 3DS Core Security Standard v1.0 is the security standard for environments running ACS, DS and 3DS Server components. It covers a baseline part and 3DS-specific requirements (including protecting protocol keys in HSMs). It applies to entities performing or supporting these functions – not to ordinary merchants.
How does Patronusec help 3DS service providers?
We support the environmental track: we set the 3DE boundary, run a gap analysis against PCI 3DS (baseline and 3DS requirements), plan remediation and prepare the organisation for assessment. After a free scope-assessment call we present a fixed-price quote matched to the role (ACS, DS or 3DS Server).
Recommend reading
A reading path for payment authentication:
- Card, BLIK, BNPL, instalments or bank transfer – comparing 5 e-commerce payment methods – context: where 3DS sits among payment methods.
- Agentic payment providers, Visa and PCI DSS – the future of authentication when the buyer is an agent.
- PCI DSS compliance: navigating the scope without confusion – how a 3DS environment sits next to PCI DSS scope.
3-D Secure and PCI 3DS – free consultation
Patronusec, an accredited QSA, supports ACS, DS and 3DS Server providers with PCI 3DS certification. If you are considering providing 3DS services, book a free scope-assessment call.
Book a consultation | PCI DSS certification | PCI gap analysis
