How to maximize frictionless rate for 3D Secure
Integrating EMV 3D Secure (3DS) 2.x into your payment flow is essential for balancing strong fraud prevention with minimal customer friction and high transaction approval rates.
A well-designed 3DS integration benefits merchants and PSPs by enabling liability shift for fraud, improving authorization approval rates, and supporting compliance with global regulatory requirements. Conversely, a poorly implemented 3DS flow can introduce unnecessary friction, leading to checkout abandonment and lost sales. The EMV 3DS 2.x standard significantly improves on 3DS 1.0 by enabling frictionless authentication (invisible to the cardholder where possible) and providing robust support for modern mobile and app-based checkout experiences.
The EMV 3DS 2.x standard significantly improves on 3DS 1.0 by enabling frictionless authentication and supporting modern browser‑ and app‑based checkout experiences.
Frictionless vs. Challenge Flows
- Frictionless flow: The card issuer’s Access Control Server (ACS) authenticates the cardholder in the background using risk-based analysis of the data provided by the merchant. The transaction proceeds without any visible interaction from the cardholder.
- Challenge flow: The issuer requires additional cardholder verification (for example, a one-time passcode, biometric authentication, or app-based confirmation). This introduces extra steps and additional friction during checkout.
Impact on Transaction Acceptance Rates
The transaction acceptance rate represents the percentage of transactions approved by the issuer. An effective 3DS integration improves acceptance in two key ways:
- Preventing issuer declines: In markets with mandatory authentication, issuers may automatically decline transactions that do not include the required 3DS authentication. Supporting SCA through 3DS is therefore essential to avoid avoidable declines. Certain exceptions may apply, such as merchant-initiated transactions or eligible low-value and low-risk exemptions.
- Reducing customer drop‑off: Additional authentication steps increase the likelihood of cart abandonment. Each abandoned authentication represents a lost sale. Increasing frictionless authentication rates directly reduces drop-offs and improves the number of successfully completed transactions.
Best Practices to Maximize Frictionless Authentication
Share Comprehensive Transaction Data
Data is critical for frictionless 3DS authentication. EMV 3DS 2.2 and later versions allow merchants to share over 100 data elements related to the transaction, device, and cardholder. Issuers use this information for risk‑based decision‑making.
Providing fewer data elements reduces issuer confidence and increases the likelihood of a challenge.
Merchants should aim to provide both mandatory and optional data fields, including (but not limited to):
- Billing and shipping address information
- Device and browser details
- Cardholder contact information
- Prior cardholder authentication and account history
Payment schemes define a subset of optional fields that are considered highly influential in issuer decision-making. These are often referred to as priority data elements and typically relate to the cardholder, their device, and their historical relationship with the merchant.
High‑Impact Data Elements
- Cardholder billing and shipping address
- Cardholder email address
- Cardholder phone number
- Merchant‑specific cardholder identifier
Cardholder Account and Purchase History Parameters
The following parameters describe the cardholder’s historical interaction with the merchant. These fields are particularly important when the cardholder has an account with the merchant (via website or mobile application).
Account Authentication Details
| Parameter name | Description |
|---|---|
customParameters[ReqAuthMethod] |
Indicates how the cardholder authenticated when logging into the merchant
system during checkout.
Possible values: 01 – No authentication (guest checkout) 02 – Login using merchant credentials 03 – Login using federated ID 04 – Login using issuer credentials 05 – Login using third‑party authentication 06 – Login using FIDO Authenticator |
customParameters[ReqAuthTimestamp] |
Date and time of the cardholder’s last login to the merchant system.
Format: YYYYMMDDHHMM |
Account Age and Changes
| Parameter name | Description |
|---|---|
customParameters[AccountAgeIndicator] |
Length of time the cardholder account has existed.
Values: 01 – No account (guest checkout) 02 – Created during this transaction 03 – Less than 30 days 04 – 30–60 days 05 – More than 60 days |
customParameters[AccountDate] |
Date the cardholder account was created.
Format: YYYYMMDD |
customParameters[AccountChangeDate] |
Date the cardholder account details were last changed.
Format: YYYYMMDD |
customParameters[AccountChangeIndicator] |
Time since the last account change.
Values follow the same definitions as AccountAgeIndicator. |
Password and Security Changes
| Parameter name | Description |
|---|---|
customParameters[AccountPasswordChangeDate] |
Date of the last password change or account reset.
Format: YYYYMMDD |
customParameters[AccountPasswordChangeIndicator] |
Time since the last password change.
Values follow the same definitions as AccountAgeIndicator. |
Purchase and Shipping History
| Parameter name | Description |
|---|---|
customParameters[AccountPurchaseCount] |
Number of purchases made by the cardholder in the previous six months. |
customParameters[ShipAddressUsageDate] |
Date the shipping address was first used.
Format: YYYYMMDD |
customParameters[ShipAddressUsageIndicator] |
Time since the shipping address was first used.
Values follow the same definitions as AccountAgeIndicator. |
Order Characteristics
| Parameter name | Description |
|---|---|
customParameters[ReorderItemsIndicator] |
Indicates whether the cardholder is reordering previously purchased items.
01 – First‑time order 02 – Reorder |
customParameters[PreOrderPurchaseIndicator] |
Indicates whether the order contains items with future availability.
01 – Merchandise available 02 – Future availability |
customParameters[PreOrderDate] |
Expected availability date for pre‑ordered items.
Format: YYYYMMDD |