What it means
When a shopper enters card details at an online checkout, the merchant can pass data about the purchase and the device through a 3DS flow to the card issuer. The issuer then decides whether it is satisfied or wants extra confirmation from the cardholder.
This step is separate from the payment authorisation and settlement that follow. EMVCo, the body that maintains the EMV 3-D Secure specifications, describes two paths.
In a frictionless flow the shared data lets the issuer approve without asking the buyer anything, and in a challenge flow the buyer must confirm through a banking app, a one-time code or another issuer method. A customer who sees no code has therefore not necessarily bypassed 3DS.
3DS can reduce some card-not-present fraud, which is fraud where the card is not physically shown, as in online shopping. It cannot stop every stolen-account purchase or settle delivery disputes, so fraud screening and customer service remain necessary.
Card network rules, region and transaction type can also affect who is liable for a chargeback, so a merchant should not promise an automatic liability shift. Most merchants switch on 3DS through a payment provider or gateway instead of building the protocol themselves.
Integration quality matters, because it affects the data reaching the issuer and the rate of failed or abandoned challenges. Managers should watch the trade-off between security and friction.
A confusing challenge can lose sales, but turning off a required flow just to lift the checkout rate can be a mistake, and rules for repeat or merchant-initiated payments differ from those for new purchases, so check the provider's current guidance. A challenge can fail even when a genuine buyer is present, so the checkout should offer a safe retry or another accepted payment method.
Staff should never ask customers to read out one-time codes, and a neutral failure message is better than implying the buyer is a fraudster.
In practice
Real-world examples.
Example
An online bookshop sends a high-value order for authentication. The issuer asks the buyer to approve the purchase in its banking app, and only after that does the shop request payment authorisation. The buyer finishes in under a minute, and the shop records the authentication result with the order.
Example
A subscription software company sees a low-risk repeat customer complete checkout with no extra screen. Its payment log still records a 3DS result, so staff learn not to assume that every authenticated payment shows a code. Support agents are told to check the payment log before telling a customer that authentication was skipped.
Example
An event ticket seller investigates failed challenges by issuer and device type. It finds that a mobile app redirection problem causes many failures, and fixing the integration improves the buyer experience without weakening security. Checkout completion on that device type rises as a result.
Formula
Calculation
Authentication success rate = successfully authenticated attempts / attempts sent for authentication x 100%.
Suppose a merchant sends 1,000 attempts for authentication and 920 succeed. The success rate is 920 / 1,000 = 0.92, or 92%.
The other 80 attempts should be split by cause, because each needs a different fix. For example, 30 issuer declines + 20 technical errors + 30 customer abandonments = 80, which together with the 920 successes accounts for all 1,000 attempts. Here abandonment alone is 30 / 1,000 = 3% of attempts.Case study
Seen in the real world.
In this fictional and illustrative case, Harbor Books, an invented online bookseller, enables 3DS through its payment provider. It sees some app challenges and some frictionless results, and its reports show authentication, authorisation and disputes as separate numbers.
The team compares authentication failures with device and issuer patterns and fixes a redirect problem on one phone browser. It does not tell management that every dispute is now the issuer's responsibility, because a customer claiming a parcel never arrived is a delivery question that authentication does not answer.
The finance manager adds one line to the monthly report for each stage: attempts, frictionless results, challenges, failures, authorisations and disputes. Over several months the team can see whether a change at checkout helped, and it keeps shipping records so that delivery disputes can be answered with the right evidence.
Watch out
Common mistakes.
- Assuming every 3DS payment shows an SMS code, when many low-risk payments follow a frictionless path.
- Treating authentication as proof of authorisation or delivery, when each answers a different question.
- Promising a universal chargeback liability shift, when liability depends on network rules, region and the transaction outcome.
Questions
People also ask.
Does every buyer get a challenge?
No. Some transactions follow a frictionless path where the issuer approves based on the data already shared.
Does 3DS approve the payment?
Not by itself. Authorisation is a separate step that the issuer completes after authentication.
Does it eliminate fraud?
No. It is one control within a broader payment process that also needs fraud screening and customer service.
From the founder's library
Take it further with the book.
Build your financial confidence beyond this definition. Shihan's full-length guide, Accounting Fundamentals, takes the same plain-English approach and turns it into a complete, practical playbook for non-finance managers, business owners and students - with chapter-end quiz answers and presentation slides included.
25% off with code MMHQ25, applied at checkout. Priced in USD - checkout may show the equivalent in your local currency.
View the book and save 25%