How Merchants Should Measure 3D Secure Performance

Many merchants judge 3D Secure by a single figure, if they measure it at all: an authentication success rate, or a chargeback rate. Neither tells you where a sale was lost or whether authentication is protecting you. A checkout can show a healthy success rate while one issuer times out for a whole evening, or while authenticated transactions quietly lose their protection at authorisation.

EMV 3DS returns a detailed record for every attempt: transaction status, reason codes, the ECI and the channel. Used properly, that record lets you trace each lost sale to its cause. Issuers measure different things for different reasons; our article on what issuers should measure covers that side.

Why one success rate hides the problem

Authentication can fail for very different reasons, and each needs a different fix. An issuer declining because it suspects fraud is working as intended. A cardholder abandoning a challenge on a mobile browser points to a display or usability problem. An ACS timing out is a capacity problem on the issuer side. A single success rate blends all three, so it cannot tell you which one to work on.

The authentication funnel, stage by stage

Treat authentication as a funnel and measure each stage separately.

Stage	What to measure	Where the data comes from	Decision it informs
1. Eligibility	Share of card payments sent to 3DS versus routed around it (exemptions, card ranges not enrolled, merchant rules)	Checkout and 3DS Server records	Routing policy; whether card range data is current
2. First response	Distribution of transaction status in the Authentication Response (ARes): Y, A, C, N, U, R and others	ARes	Data quality and issuer behaviour
3. Frictionless share	Outcomes completed without a challenge, as a share of requests	ARes	Whether the data you send gives issuers enough confidence
4. Challenge completion	Challenges that reach a successful final result	Results Request (RReq)	Challenge display and cardholder experience
5. Abandonment and timeouts	Challenge cancellation indicators and timeout reason codes	RReq	Usability, timeouts and out-of-band flows
6. Unsuccessful outcomes	N, U and R by reason code	ARes and RReq	Separating issuer risk decisions from technical failures
7. Authorisation after authentication	Approval rate split by ECI	Authorisation responses	Whether authentication data reaches the issuer intact
8. Disputes	Fraud and non-fraud disputes split by ECI and authentication outcome	Dispute and chargeback data	Whether liability protection is working
9. Cost	Authentication cost per completed order	Provider and scheme invoices	Routing economics

In a frictionless authentication the ARes holds the final result. In a challenged one, the final result arrives in the RReq. Reporting that only reads the ARes will miscount every challenge, as why the 3DS transaction status differs between messages explains.

Read the reason codes, not only the status

When authentication is unsuccessful, EMV 3DS provides a transaction status reason (transStatusReason) alongside the status. Grouping those reasons separates problems you can fix from decisions the issuer has made. Examples from the values EMVCo defines:

Group	Example reason codes	What it usually means for a merchant
Issuer risk decision	10 (stolen card), 12 (transaction not permitted to cardholder)	The issuer is doing its job. Investigate only if volumes change suddenly.
Limits	04 (exceeds authentication frequency limit), 19 (exceeds ACS maximum challenges)	Repeated attempts on the same card; can indicate retries in your checkout or card testing
Technical or capacity	14 (transaction timed out at the ACS), 22 (ACS technical issue)	Issuer-side availability; apply your fallback policy and watch by issuer
Capability	20 (non-payment transaction not supported), 21 (3RI transaction not supported)	The issuer does not support the message type you sent; adjust routing
Directory Server specific	80 to 99 (reserved for DS use)	Scheme-defined meanings; look them up per scheme

 

Protocol errors are a separate category from unsuccessful authentications. They arrive as Error messages with their own codes, covered in how 3DS error codes and the Error message work.

Segment before you draw conclusions

Aggregate figures hide most of the useful patterns. Break every measure down by:

• issuer or card number range
• card scheme
• channel (browser or app) and, for browser, device type and browser
• protocol version
• transaction type and order value band
• new or returning customer
• domestic or cross-border card

A problem confined to one issuer, one browser or one protocol version usually has a specific, fixable cause. The same problem averaged across all traffic looks like a small dip.

Link authentication to what happens next

Stages 7 and 8 are the ones merchants most often cannot measure, because authentication, authorisation and dispute data sit in different systems. Joining them needs a shared key. The DS Transaction ID and the 3DS Server transaction identifier are the natural candidates; store them with the order so authorisation and dispute records can be matched back to the authentication.

This matters beyond liability. Visa’s Acquirer Monitoring Program counts fraud reports and disputes together against settled card-not-present transactions, and from 1 April 2026 the excessive merchant threshold in Asia Pacific, Canada, Europe and the United States fell to 150 basis points. Knowing which of your disputes came from authenticated transactions, and which did not, is part of managing that ratio.

Turning patterns into decisions

Once the funnel is in place, recurring patterns point to specific causes.

Pattern	Likely cause	Where to look next
One issuer challenges far more than others for similar customers	That issuer’s risk model lacks data it relies on	Requestor data quality and the 3DS Method
Spikes in U with reason 14 or 22 for one issuer	ACS availability	Your fallback policy for that issuer
Challenge abandonment concentrated on mobile browsers	Challenge display or out-of-band handoff	Challenge iframe requirements and browser out-of-band failures on mobile
Authenticated transactions (ECI 05 or 02) declining at authorisation more than expected	Authentication data lost in the hand-off, or issuer decision	Trace the hand-off with your acquirer
Fraud chargebacks on fully authenticated transactions	Broken hand-off, or the dispute is not a fraud dispute	Dispute reason codes; authentication values received at authorisation
Authentication requests rising faster than orders, with more frequency-limit reasons	Possible card testing	Velocity controls before authentication

What your reporting needs to capture

Whichever 3DS Server and gateway you use, confirm you can extract, for every attempt: the transaction status from both ARes and RReq, the reason code, the challenge cancellation indicator, the ECI, the channel and protocol version, the DS Transaction ID and a timestamp for each message. Without these fields, most of the funnel cannot be built.

Frequently asked questions

What is a good frictionless rate?

There is no reliable universal figure. Frictionless rates vary with market, issuer mix, product, order value and the quality of data a merchant sends. Published benchmarks rarely state their methodology. A more useful target is your own baseline, by segment, improving over time.

Should the 3DS provider or the merchant own this reporting?

Usually both. The 3DS Server holds authentication data; the merchant or its gateway holds authorisation and dispute data. The merchant is normally the only party that can join them, so it should own the end-to-end view.

Connecting your authentication data

GPayments’ ActiveServer is a 3DS Server used by acquirers, payment gateways, PSPs and merchants. If you want help working out what your authentication data can tell you, or how to connect it to authorisation and dispute outcomes, speak with a GPayments 3DS specialist.