3DS is an authentication protocol for online card transactions. It adds an additional security verification layer to card payments. ONERWAY Issuing cards support 3DS risk authentication, which helps card networks, acquirers, and issuers make authentication decisions in selected online transaction scenarios and reduce the risk of fraud and unauthorized transactions.
3DS stands for 3-D Secure. It usually involves the issuer, acquirer, and card network. After a cardholder initiates an online payment, transaction information is routed through the card network to the issuer side for authentication decisions.
During authentication, the system evaluates risk based on factors such as transaction amount, merchant information, device information, regional rules, and historical transaction behavior. It then determines whether the cardholder needs to complete additional verification.
3DS2 balances security and payment experience. Low-risk transactions or transactions with sufficient information may complete authentication through a frictionless flow. When transaction risk is higher or authentication information is insufficient, the cardholder may need to complete additional verification.
| Authentication experience | Description | Cardholder experience |
|---|---|---|
| Frictionless authentication | For low-risk transactions or transactions with sufficient information, the system may complete the authentication decision without requiring additional cardholder action. | Usually no obvious interaction |
| Challenge authentication | When transaction risk is higher, rules require stronger authentication, or authentication information is insufficient, the cardholder may need to complete additional verification. | An authentication page, confirmation action, or one-time password may appear |
Not every online transaction enters the 3DS flow. Whether 3DS is triggered, and what authentication experience follows, usually depends on the transaction scenario, acquirer requirements, card network rules, regional regulatory requirements, and risk assessment result.
Common risk assessment factors include:
Therefore, 3DS should not be understood as “the cardholder enters an OTP every time.” OTP (One-Time Password) is only one possible verification method in a challenge flow. The actual authentication experience depends on the result returned by the transaction flow.
When a transaction requires challenge authentication, the system may require the cardholder to complete OTP (One-Time Password) verification. ONERWAY Issuing currently sends OTPs to the cardholder’s registered email address.
If challenge authentication is not triggered, the cardholder usually does not receive an OTP and does not need to enter a verification code.
When a transaction enters the 3DS flow, the authentication result affects whether the transaction continues to authorization. Even if 3DS authentication succeeds, the final transaction may still fail because of insufficient balance, abnormal card status, merchant restrictions, risk rules, or other authorization reasons.
| Scenario | Description |
|---|---|
| 3DS not triggered | The transaction continues through the normal authorization flow |
| Frictionless authentication completed | Authentication is completed without cardholder interaction, and the transaction continues to authorization |
| Challenge authentication completed | The cardholder completes the required verification, and the transaction continues to authorization |
| Authentication failed, canceled, or timed out | The transaction may be declined or terminated |
One important purpose of 3DS is to reduce unauthorized transaction risk and, when card network rules are met, provide a basis for liability shift in fraud disputes.
After the cardholder successfully completes 3DS authentication, if a fraud-related dispute is later raised for the transaction, liability may shift from the merchant side to the issuer side or another party defined by card network rules. This can reduce the merchant’s exposure to fraud losses.
Liability shift does not apply to all transactions, and successful 3DS authentication does not guarantee that a transaction will never be disputed. Whether liability shifts depends on card network rules, authentication results, transaction type, transaction evidence, and dispute reason.
Data security and compliance requirements
Learn about card data protection, transaction risk control, identity checks, AML requirements, and compliance responsibility boundaries in issuing.
Integration flow
Onerway Issuing API integration flow covering preparation, environment configuration, card creation, transaction queries, and event webhooks.