3D Secure (3DS) in Card Payments

A guide for developers and product owners based on real-world integration

What is 3DS?

When I first heard of 3DS I thought it is just another security check slapped on top of a card payment. But digging into it I realized it is a full blown protocol that introduces a way for the cardholder to be authenticated by their bank during online transactions.

The 3D in 3DS stands for Three Domains and that is not just a fancy name. It refers to three distinct players involved

The Issuer domain (customer’s bank).
The Acquirer domain (merchant and their payment processor).
The Interoperability domain (systems that route and verify the 3DS request — more on that later).

The idea is very simple before money moves from account we want to be more confident that the person using the card is the real cardholder.

Why 3DS in Card Payments?

Originally, online card payments were authenticated purely by possession of the card, whoever had the card number, expiry and CVV (sometimes billing address) could make a purchase. That was okay in the early days but as fraud grew and regulations tightened this model became risky.

3DS1 was the first attempt at solving this problem. Remember those redirects to bank pages that asked you to enter an OTP? That was 3DS1

Then came 3DS2 which introduced:

Rich data sharing (browser/device info, location, etc.)
Frictionless authentication options.
Support for mobile apps and in-app payments.

The goal was not just to reduce fraud but to balance security and user convenience.

Architecture: How 3DS Fits into the Card Payment Flow

A user enters card details at checkout page and before initiating the authorize of transaction, we first initiate a 3DS check by calling to the 3DS Server (hosted by a provider like Netcetera or Smart Interface).
The 3DS Server asks the Directory Servers to identify whether the card’s bank (issuer) supports 3DS and what version. the Directory Server routes the request to the ACS (Access Control Server) of the issuing bank.
The ACS decides can we approve silently (frictionless) or do we need to challenge the user (challenge flow). If challenge is needed, ACS returns the challenge url which we display an iframe or a mobile challenge UI for user input. (typically issuing bank’s OTP page in case of browser)
Once authentication is done we get a signed response from 3DS Server, we include this 3ds response when authorizing the payment with the gateway.

What surprised me was how many moving parts are involved and how fragile things get if one of them isn’t wired correctly.

Core Components in 3DS

3D Secure (3DS) involves several key systems working together. Each has a distinct owner, function, and role in the flow.

Directory Server (DS Server)

Who owns it? Operated by card networks (Visa → VDS, Mastercard → MDS, Amex, etc.). What it does - Checks if a card is enrolled in 3DS - Identifies which 3DS versions the issuer supports - Routes the request to the correct ACS Role in 3DS Think of it as the DNS of 3DS : it translates the card number into routing info so we know which ACS to talk to.

Access Control Server (ACS)

Who owns it? Run by the issuing bank (or their outsourced vendor). What it does - Authenticates the cardholder (frictionless risk check or challenge flow) - Decides if the transaction can be trusted without further user action - Issues the cryptographic response (CAVV, ECI, etc.) that proves authentication happened Role in 3DS It’s the gatekeeper : the final authority on whether the transaction is genuine and should be approved.

Payment Gateway

Who owns it? Merchant-facing providers such as Stripe, Razorpay, or a custom acquirer. What it does - Processes the payment after 3DS authentication - Accepts 3DS outputs (ECI, CAVV, transStatus) as part of the authorization request Role in 3DS The gateway doesn’t perform authentication — it relies on the 3DS result . Some gateways bundle 3DS internally, but in our flow we handle it separately and then pass the 3DS values along during authorization.

3DS authentication end to end flow

3DS Versioning

Before an actual authentication can start, the 3DS Server first needs to know what protocol versions and capabilities are supported by the issuer’s ACS (Access Control Server) and the Directory Server (DS). This is where 3DS Versioning comes into play.

When the channel is a browser, the 3ds server triggers the versioning step before sending any authentication request. In simple terms, the 3ds server:

Generates a unique threeDSServerTransID.
Request for card’s versioning data, which includes the supported protocol versions and 3DS Method URL. the 3ds server prepares a threeDSMethodDataForm for the browser to post.

If the issuer supports 3DS 2.0, the same threeDSServerTransID obtained here must also be used in the subsequent authentication request.

3DS Authentication

Once versioning is out of the way, the real authentication begins. The 3DS Server needs to:

Ensure all the required information for the AReq (Authentication Request) message is ready.
Identify which Directory Server (DS) to use and establish the secure channel with the DS.
Send the AReq message over that channel.

For browser-based flows, the threeDSServerTransID from the versioning step is carried forward into this request.

The DS then returns a response, and depending on the outcome the 3DS Server will:

For successful authentication → send back a ThreeDSServerAuthenticationResponse confirming success.
For a challenge flow → generate a CReq message and send a response indicating cardholder interaction is required.
For failed authentication → send a response that clearly marks it as unsuccessful.

3DS Results

The Results Request (RReq) is the issuer’s way of confirming the outcome of an authentication. It is always sent through the DS to the 3DS Server but only in flows where a cardholder challenge was involved.

When the server receives an RReq, it will:

Validate and log the incoming data and generate Results Response (RRes) back to the DS.
Optionally push a ThreeDSServerResultsResponse to the merchant’s Results Response Notification URL (or allow the merchant to pull the results from an endpoint).

This ensures that the merchant has a final and reliable record of how the authentication turned out.

3DS Challenge

The Challenge Response (CRes) is the last step in a challenge-based authentication flow. Once the cardholder has interacted with the issuer (e.g., entering OTP, biometric, or app confirmation), the ACS sends the final result.

Here’s how it flows:

The ACS posts a base64-encoded CRes message back to the merchant’s Notification URL.
The 3DS Server provides an endpoint where this base64 message can be sent as a JSON payload (ThreeDSServerFinalCResRequest).
The server decodes, validates, and logs it, then returns a structured ThreeDSServerChallengeResponse. If errors are found, they are included in this response as well.

At this point, the authentication cycle is complete, and the merchant knows whether the cardholder successfully passed the challenge or not.

Frictionless vs. Challenge Flows in 3DS

These two flows define the actual user experience and if you are in product or growth this part matters a lot.

1. Frictionless Flow

This is when the issuer is confident enough to authenticate without any user interaction. The user sees nothing the check happens behind the scenes.

In one of our use case a returning user made a low-value purchase from the same device, and the issuer simply returned a “Y” (authenticated) without showing anything.

Behind the scenes we had sent device info, IP address, browser headers, and some merchant risk data and it worked.

2. Challenge Flow

This kicks in when the issuer decides the transaction looks risky. The user is shown a challenge screen typically via an embedded iframe where user are asked to verify with OTP, biometric, or app push.

The ACS sends us a URL (acsURL) and a payload (creq), and we render that in a full-page or inline iframe. Once the challenge is done, we get the result back (transStatus: Y/N/U) and proceed with authorization.

Final Thoughts

3DS looked overwhelming at first but once I saw it as a network of decision makers (our server, the DS, the ACS, and the issuer) things started to click. It is less about authentication logic and more about smart routing, careful data sharing, and good UX handling.

Blog post