3DS is an authentication protocol for online card transactions. It adds an additional layer of security verification for card payments. ONERWAY Issuing cards support 3DS risk authentication capabilities in certain online transaction scenarios, working with card networks, acquirers, and issuers to complete authentication decisions and help reduce fraud and unauthorized transaction risks.
3DS stands for 3-D Secure. It usually involves coordination between 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, and determines whether the cardholder needs to complete additional verification.
The 3DS path depends on the risk assessment result, and not every transaction enters OTP 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 be required to complete additional verification.
| Authentication experience | Description | Cardholder experience |
|---|---|---|
| Frictionless authentication | Low-risk transactions or transactions with sufficient information may be authenticated by the system without additional cardholder action. | Usually no obvious interruption |
| Challenge authentication | When transaction risk is higher, stronger authentication is required by rules, 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 a 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 decision results.
Common risk assessment factors include:
Therefore, 3DS should not be understood as “OTP is required every time.” OTP (One-Time Password) is only one possible verification method in a challenge authentication 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. Current issuing capabilities send the OTP 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 due to insufficient balance, abnormal card status, merchant restrictions, risk control 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 obvious 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 role of 3DS is to help 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 dispute is later raised for the transaction, liability may shift from the merchant side to the issuer side or another liable party defined by card network rules, reducing the risk that the merchant bears the fraud loss.
Liability shift does not apply to all transactions, and passing 3DS authentication does not mean a transaction cannot later be disputed. Whether liability shift applies still 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.