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

Source: https://payneteasy.com/blog/3ds-verification

_3DS verification explained: frictionless vs challenge flows, SCA exemptions, why checks fail, and what your payment gateway should let you control._

3DS verification is the moment in an online card payment when the card issuer checks that the person paying is the real cardholder.

03.11.2026 9 min read

![3DS Verification Explained: How It Works, Why It Fails, What You Control](https://payneteasy.com/static/img/blog/3ds-verification/1.webp)

By [**Daniel Karpilovsky**](https://payneteasy.com/authors/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)?](https://payneteasy.com/glossary/what-is-3ds-3d-secure). For what changed between versions, see [3DS2 – a new level of security](https://payneteasy.com/blog/3ds2-a-new-level-of-security-whats-new-and-how-to-transit).

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

| Participant | Role in 3DS verification |
| --- | --- |
| Cardholder | Pays and, if asked, confirms their identity in the bank app, with a one-time code or with biometrics |
| Merchant (3DS Requestor) | Starts verification and passes payment and device data |
| 3DS Server | Software on the merchant or gateway side that builds and sends the authentication request |
| Directory Server (DS) | Run by the card scheme; routes the request to the right issuer |
| Access Control Server (ACS) | Run by or for the issuer; assesses risk and decides whether to challenge |
| Acquirer | Receives the authorization request with the authentication result attached |

## 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

|     | Frictionless flow | Challenge flow |
| --- | --- | --- |
| What the shopper sees | Nothing extra | Bank screen, app push, one-time code or biometrics |
| Who decides | Issuer's ACS, based on risk data | Issuer’s ACS, based on risk data or regulation; the merchant can state a challenge preference, but the ACS decides |
| What triggers it | Complete, consistent data and a low-risk payment | Higher risk, missing data, SCA required with no exemption |
| Where payments are lost | Rarely at this step | Abandonment, timeouts, wrong codes |

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](https://payneteasy.com/solutions/3ds_adapter). The issuer still has the last word.

## Verification outcomes

| Status | Meaning | Typical next step |
| --- | --- | --- |
| Y   | Authenticated | Proceed to authorization with the authentication value |
| A   | Attempted: full authentication was not possible, proof of attempt provided | Proceed; liability treatment depends on scheme rules |
| C   | Challenge required | Show the challenge |
| N   | Not authenticated | Do not proceed as authenticated; offer another card |
| U   | Authentication could not be performed (technical issue) | Follow your policy: retry, or proceed without authentication where SCA does not apply and accept the fraud liability |
| R   | Rejected by the issuer | Do not proceed |

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](https://payneteasy.com/blog/psd2-what-is-strong-client-authentication) 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

| Cause | What happens | What to do |
| --- | --- | --- |
| Incomplete or inconsistent data | Issuer cannot assess risk and challenges more often | Send full browser, device and cardholder data; keep it consistent with the authorization |
| Device data step skipped or timed out | ACS gets less data, so more challenges | Run the 3DS Method step and wait for it to complete (the protocol allows up to 10 seconds) before the authentication request; if it times out, send the request and flag that the step did not complete |
| Shopper abandons the challenge | Payment ends unauthenticated | Mobile-friendly challenge (in-app SDK), clear messaging at checkout |
| Wrong one-time code or expired session | Status N, or U on some ACS | Let the customer retry or use another card |
| Issuer ACS unavailable | Status U | Decide in advance: retry later, or proceed without 3DS where your rules and region allow |
| Card or issuer does not support the protocol version | No EMV 3DS available | Set a fallback policy per market |
| Soft decline after an exemption request | Issuer wants SCA | Re-run with 3DS instead of repeating the same request |

## 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](https://payneteasy.com/solutions/3ds_adapter) · [White-label payment gateway](https://payneteasy.com/solutions/gateway) · [Payment orchestration platform](https://payneteasy.com/solutions/orchestration-payment-platform)

**Next step.** Planning 3DS for your merchants or for your own gateway? [Talk to the Payneteasy team](https://payneteasy.com/contacts) about the setup you need.

## Frequently Asked Questions

### What is 3DS verification?

The step in an online card payment where the issuer confirms that the payer is the cardholder, either silently (frictionless) or by asking for a code, biometrics or app confirmation (challenge).

### Is 3DS verification mandatory?

In the EEA and the UK, most customer-initiated online card payments need Strong Customer Authentication, and 3DS is the standard way to provide it. Elsewhere it depends on scheme rules, the issuer and your own risk policy.

### Does passing 3DS mean the payment is approved?

No. 3DS confirms the cardholder; authorization approves the payment. A verified payment can still be declined.

### Does 3DS verification hurt conversion?

With EMV 3DS, many low-risk payments pass without a challenge. How often depends on the issuer and on the quality of the data you send. Challenges are where most drop-off happens.

### Can a gateway decide when to run 3DS?

Within the rules, yes. It can apply 3DS selectively and request exemptions, but the issuer makes the final call and can still require a challenge.