3DS Verification Explained: How It Works, Why It Fails, What You Control

By Daniel Karpilovsky, Head of Success, Payneteasy

3DS verification is the moment in an online card payment when the card issuer checks that the person paying is the real cardholder. Done well, most low-risk payments pass without the shopper noticing. Done badly, it becomes the step where good customers drop out. This guide covers the whole process: who takes part, what happens step by step, why verification fails, and which parts a merchant or payment service provider (PSP) can actually control.

What 3DS verification is

3-D Secure (3DS) is the EMVCo protocol that card schemes use to authenticate the cardholder in card-not-present payments. Visa Secure, Mastercard Identity Check, American Express SafeKey and JCB J/Secure are all built on it. The current version is EMV 3DS, often called 3DS2. The major schemes have retired the original 3DS 1.0.2 in most markets. For the basic definition, see What is 3DS (3-D Secure)?. For what changed between versions, see 3DS2 – a new level of security.

3DS answers one question: "is this the cardholder?" It does not answer "are there funds?" That is still the job of authorization.

Who takes part

Step by step

1. Device data collection. Before the authentication request, the checkout page or app SDK collects browser or device data. In browser flows this is the "3DS Method" step.
2. Authentication request. The 3DS Server sends payment, cardholder and device data through the Directory Server to the issuer's ACS.
3. Risk assessment. The ACS scores the payment using that data and its own history for the card.
4. Frictionless or challenge. If the risk is low, the ACS authenticates without involving the shopper. If the risk is higher or the rules require it, the shopper gets a challenge.
5. Result. The ACS returns a result status. A successful or attempted authentication (Y or A) also returns a cryptographic authentication value and an ECI (electronic commerce indicator).
6. Authorization. The authorization request goes to the acquirer with that value attached, and the issuer then decides on the payment itself.

Frictionless vs challenge

The lever a merchant or PSP controls most directly is data. The more complete and consistent the request, the more often the issuer can decide without a challenge. The issuer still has the last word.

Verification outcomes

EMV 3DS 2.2 also adds D (challenge required, decoupled authentication confirmed) and I (informational only: the issuer acknowledged the merchant’s challenge preference, with no authentication outcome and no liability shift).

Verification is not authorization

A payment can pass 3DS verification and still be declined at authorization because of insufficient funds, card limits or the issuer's own fraud rules. The reverse also happens. An issuer that receives an unauthenticated payment where strong authentication is required can return a “soft decline” (for example, response code 1A on Visa or 65 on Mastercard), meaning “authenticate and try again”. Treat it as a cue to run 3DS, not as a final refusal.

A timeout is not a failure either. A payment can end up with an unknown status while the issuer's answer is still pending, in 3DS and non-3DS flows alike. Check the final status before retrying, or you risk charging the customer twice.

Liability shift

When a payment is successfully authenticated with 3DS, liability for certain fraud-related chargebacks can move from the merchant to the issuer. Whether it does depends on scheme rules, the result status and the type of dispute. It covers fraud claims ("I did not make this payment"), not disputes about goods or services. Treat liability shift as a benefit of good authentication, not a guarantee.

SCA and exemptions

In the European Economic Area, Strong Customer Authentication (SCA) under PSD2 requires two independent factors from different categories (something the customer knows, has or is) for most customer-initiated online payments. The UK applies equivalent SCA rules under its own regulation. 3DS is the standard way card payments meet that requirement. The rules also allow exemptions and out-of-scope cases, for example:

• low-value payments below a set threshold, with cumulative limits;
• transaction risk analysis (TRA), when the acquirer's or issuer's fraud rate is low enough;
• trusted beneficiaries that the cardholder has whitelisted with their bank;
• recurring payments of the same amount to the same merchant, after the first one is authenticated;
• merchant-initiated transactions, which are outside SCA scope when set up correctly;
• secure corporate payments.

An exemption is a request, not a right: the issuer can still ask for a challenge or send a soft decline. Thresholds and fraud-rate bands are set by regulation and can change, so confirm them with your acquirer before you build rules around them.

Why 3DS verification fails and what to do

3DS and payment routing

If you work with several acquirers, plan 3DS together with routing. The authentication request is made on behalf of a specific acquirer, and that acquirer's identifiers travel in the request. Suppose a payment is cascaded to a different acquirer after a decline. Whether the earlier authentication can be reused then depends on scheme and acquirer rules, and in many setups the payment has to be authenticated again. Your platform should make that choice explicit instead of leaving it to chance.

What your gateway's 3DS layer should let you control

• when 3DS runs: per merchant, per market, per risk level;
• which exemptions to request and what happens when the issuer refuses one;
• fallback behavior when the issuer's server is unavailable;
• how 3DS works with routing and cascading;
• test cards and amounts for each flow before go-live;
• clear statuses in reporting, so support can tell "not authenticated" from "declined".

How Payneteasy handles 3DS verification

Payneteasy is a payment technology and orchestration layer, not a payment facilitator: your acquiring contracts and risk policies stay yours. 3DS verification is part of that layer:

• 3DS Adapter is a built-in component of the Payneteasy white-label payment gateway. It supports EMV 3DS 2.x, manages authentication flows and works with Visa, Mastercard, JCB and American Express.
• Per-merchant 3DS policies. Each merchant project can define when authentication is required, how exemptions are applied and what the fallback is. A PSP can therefore offer different 3DS setups to different merchant segments.
• Selective authentication. Smart 3DS routing sends a payment through 3DS where it is needed, instead of authenticating every payment, while meeting SCA requirements where they apply.
• Documented flows and a test sandbox. The integration documentation describes non-3D, frictionless and challenge flows and the 3DS Decision Making Schema for each use case. In the sandbox, test amounts trigger frictionless, challenge and error outcomes, and test cards emulate delays in the 3DS Method step, so you can check timeout handling before go-live.

Explore: 3DS Adapter · White-label payment gateway · Payment orchestration platform

Next step. Planning 3DS for your merchants or for your own gateway? Talk to the Payneteasy team about the setup you need.