3-D Secure

3-D Secure adds another layer of protection for merchants and cardholders. When enabled, the card-issuing bank authenticates each transaction with a second factor—an OTP or SMS token—which significantly reduces fraud risk.

Is 3-D Secure mandatory for my business?

How do I enable 3-D Secure?

3-D Secure is an account-level setting, not something you request or configure per charge — once it's enabled on your account, Omise applies it automatically to the transactions that need it.

If Omise's fraud analysts haven't already flagged your account for mandatory review, and the guidance in When 3-D Secure helps convinces you it's worth turning on, contact support@omise.co to request it. Omise enables the service on your test account first; once you've confirmed your integration handles it correctly, Omise enables it on your live account too.

When 3-D Secure helps

3-D Secure is advantageous for merchants offering:

• Travel bookings
• Game money, digital money, or prepaid cards
• Digital goods such as music, movies, and software
• Rental services or sales of high-priced products
• Any online content where fraud and chargebacks occur frequently

Consider enabling it if any of the following apply to your business:

• You've lost many chargebacks and can't provide proof of delivery.
• You've experienced many fraud cases.
• You don't need recurring payments and want stronger fraud protection.

The trade-off

Enabling 3-D Secure redirects cardholders to a bank page on every purchase, which means merchants can't process automatic or recurring payments through it directly. You can work around this with the Customer API, so cardholders don't have to re-enter their card details each time — they still authenticate with 3-D Secure whenever they make a payment, but the card details themselves are already on file.

Learn more in How to implement 3-D Secure.

How 3-D Secure 2 works

What are the features of 3DS2?

3-D Secure 2 features frictionless authentication (see How does 3DS2 authenticate a transaction?) and mobile in-app flows that authenticate transactions using enhancements such as fingerprints and facial recognition.

Accepting 3-D Secure payments

Once 3-D Secure is enabled on your account, accepting a payment follows this pattern:

1. Create a token using Omise.js, as with any other charge.
2. Create the charge with your secret key, adding a return_uri parameter — a URL on your site that the cardholder returns to after authenticating, for example, https://yoursite.com/orders/123456789/complete.
3. The charge response includes a new authorize_uri field. Redirect the cardholder to it.
4. The cardholder authenticates with their bank, then returns to the return_uri you provided.
5. Make an API request to check the charge's latest status — a completed redirect doesn't necessarily mean the charge succeeded.

Authentication typically takes 1–3 minutes because the cardholder must wait for an SMS token; it can take up to 10 minutes if they’re enrolling in 3-D Secure with their bank for the first time. Account for this in your checkout UX with a waiting state, not a hard timeout.

How does 3DS2 authenticate a transaction?

3DS2 analyzes many data points as an advanced layer of fraud protection. The cardholder enters their card details at checkout. At this point, your 3DS service provider sends an authentication request — including cardholder and device information such as device ID, MAC address, geo-location, and previous transactions — to the cardholder's bank.

The bank's 3DS service provider assesses the transaction risk, and the transaction then proceeds one of two ways:

1. If the data gives the bank enough confidence that the genuine cardholder is making the purchase, the transaction goes through the frictionless flow — authentication completes without any additional input from the cardholder, and the cardholder never receives an OTP.

1. If the bank needs further proof, it challenges the cardholder to verify their identity with an OTP, facial recognition, or a fingerprint before authenticating the payment.

The following diagram illustrates the 3DS2 flow:

The sequence splits into two parts: creating the charge, which is the same for every 3-D Secure transaction, and then one of three authentication paths, depending on what the bank decides.

Creating the charge. The cardholder submits their card details to your app or the Omise SDK, which requests a token from Omise and receives one back. Your app passes that token to your own server, which creates the charge. Omise's response includes the authorize_uri described in Accepting 3-D Secure payments; your app uses it to start authentication, Omise forwards the request to the bank, and the bank's response determines which of the three authentication paths the transaction takes.

3DS v1 (legacy). You won't encounter this path today, since the card networks decommissioned 3DS1 in October 2022 — the diagram includes it for completeness. The cardholder’s browser redirects through Omise to a full page hosted by the bank, where they enter their authentication data directly; the result then travels back through the same redirect chain before your app shows it.

3DS v2, frictionless. The bank already trusts the transaction based on the data it received, so the cardholder does nothing further — your app shows the result immediately, with no redirect and no OTP.

3DS v2, challenge. Your app collects the cardholder's authentication data — an OTP, fingerprint, or face scan — and sends it to the bank for verification, without leaving your checkout. This exchange can repeat, as shown by the loop in the diagram, if the first attempt fails, before your app shows the final result.

FAQ

What's the difference between 3DS1 and 3DS2? 3DS1 always redirected the cardholder to a bank page and required a static password or OTP for every transaction. 3DS2 adds frictionless authentication—using richer transaction data, many legitimate purchases authenticate silently, with no cardholder input. The major card networks decommissioned 3DS1 in October 2022, so 3DS2 is the only version in production today.

Do I need to do anything now that 3DS1 is retired? If your integration already uses Omise's current charge flow, no — Omise handles the 3DS2 authentication request and response. If you built a custom integration specifically for the older 3DS1 redirect flow, follow How to implement 3-D Secure to confirm you're on the current flow.

What happens if 3-D Secure authentication fails? It fails in one of two ways: an enrollment failure, where something's wrong with the setup itself (for example, a missing or misconfigured return_uri), or a validation failure, where the cardholder doesn't complete authentication (a wrong OTP or a session timeout). In either case, the charge doesn't succeed. See Testing for the specific test cards and mock authentication flows that simulate both scenarios.

Does 3-D Secure work with recurring or automatic payments? Not directly — see The trade-off. Use the Customer API to store card details on file, so the cardholder only has to complete 3-D Secure authentication itself on each payment, not re-enter their card.

How do I know if 3-D Secure blocked a charge? Check your dashboard — a charge that Omise's fraud system blocked shows a status of failed_fraud_check. See the Fraud Protection guide for how the broader fraud system works alongside 3-D Secure.

Is enabling 3-D Secure my decision, or Omise's? Both, depending on your business. For certain higher-risk business types, Omise's fraud analysts determine that it's mandatory. Otherwise, it's optional, and you can request it yourself — see How do I enable 3-D Secure?.

Does the frictionless flow protect me from chargebacks the same way the challenge flow does? Yes. Both flows carry the same liability shift — the issuing bank accepts liability for a payment dispute either way, regardless of whether the cardholder saw a challenge screen.

Related content

• How to implement 3-D Secure — Step-by-step integration guide
• Testing — Test cards and mock flows for both successful and failed 3-D Secure authentication
• Fraud Protection — How Omise's broader fraud detection system works
• Customers API — Store card details on file for recurring charges
• Charges API — The return_uri and authorize_uri fields used in the 3DS2 flow