The terms appear in gateway documentation and in merchant forums, usually without explanation: this account supports 2D, that one requires 3D, this card type bypasses the OTP step. The confusion is understandable, because “2D gateway” is not a product category. It describes how much authentication happens before a card payment is approved.
The two flows in plain terms
A 3D Secure payment sends the customer to their issuing bank for an extra check, usually a one-time password on the phone. The bank authenticates, then the payment is authorised. The three “domains” in the name are the merchant, the acquiring bank and the issuing bank.
A 2D payment authorises with the card details alone. The merchant sends the card number, expiry and CVV, and the issuer approves or declines without asking the cardholder for anything else.
The practical difference is who carries the fraud risk when a payment is disputed. With successful 3D authentication, liability generally shifts to the issuer. Without it, the merchant is exposed, and the chargeback usually succeeds.
Why India is a 3D market
Indian domestic card payments require an additional factor of authentication for most transactions, under Reserve Bank of India rules. That factor is typically the OTP or, increasingly, an app-based approval inside the bank’s own application.
The effect is that a domestic checkout in India runs on 3DS by default. A merchant asking for “2D only” is usually asking for something the domestic card networks will not grant at scale, or is describing a flow where the authentication happens invisibly through risk-based rules for low-value transactions.
Some categories have exemptions and threshold treatments, but they are narrow and defined by regulation rather than chosen by the merchant. Do not build a business model on the assumption that the OTP step can simply be removed.
Where 2D still appears
Three situations are worth knowing.
International cards outside India. Some issuers and regions treat 3DS as optional. A gateway may process those payments without a challenge, which improves conversion and raises fraud exposure.
Stored credentials and recurring mandates. Card-on-file and e-mandate flows handle authentication once and then charge subsequent cycles under a different rule set. The checkout looks like a 2D charge even though authentication happened earlier.
Legacy or misconfigured integrations. A gateway account set up years ago may still be running an old flow. This is a risk to close, not a feature to preserve.
What this means for conversion
Every extra step costs conversions. The OTP screen is no exception: customers abandon when the SMS does not arrive, when the number on file is old, or when they are on a call and miss the window.
The right response is not to remove authentication but to reduce the reasons it fails:
- send the OTP to a number the customer actually has, collected at checkout
- keep the session alive while the bank screen is open, so a slow SMS does not expire the order
- handle the “authentication failed” return properly instead of dumping the customer on an error page
- log which step failed, so you can tell a bank outage from a customer typing the wrong code
A checkout that retries gracefully converts better than one that skips the security step and pays for it in disputes.
Fraud and chargebacks
If you do run 2D for international traffic, price the risk. Card testing attacks target exactly this flow: many small payments, each below the threshold where a challenge would trigger, from a stolen card range. The costs arrive weeks later as chargebacks and a reserve on your settlements.
Basic controls: velocity limits per card and per IP, an address verification check, a minimum ticket size for unchallenged payments, and a block on mismatched country pairs. None of this is exotic, but it has to be built before the first attack, not after.
What we do
We set up the checkout so the authentication flow matches the card type and the market, with the failure paths handled properly rather than left to chance.
The build is covered under payment gateway integration, with starting fees on the payment gateway integration cost page. For provider selection, see the payment gateway comparison; for the build costs of specific providers, the Razorpay integration cost and PayU integration cost pages cover the common cases.
FAQ
Does a 2D payment mean no OTP at all?
Yes, in the strict sense: the payment is authorised without an additional authentication step. In India, domestic card rules normally require that step, so a true 2D charge is mostly seen with certain international cards or under specific exemptions.
Is 3D Secure always safer for the merchant?
For disputed card payments, usually yes, because successful authentication shifts liability to the issuer. It is not free: the extra step reduces completed orders, so the right balance depends on your average ticket and your chargeback history.
Why do some international payments fail at the OTP step?
The issuer may not support the challenge for that card or region, the customer’s number may not be registered for international transactions, or the bank may decline the authentication outright. Surfacing the reason instead of a generic failure lets the customer try another method.
Can I choose 2D for my whole checkout?
Not for domestic cards at scale. Regulations require an additional factor, and gateways enforce it. You can influence when a challenge is triggered through risk rules, but you cannot opt the domestic card business out of authentication.
Does 3D Secure add a fee?
Generally no separate fee from the gateway for using 3DS itself, though some providers bundle authentication into their transaction pricing. Ask for the line items rather than assuming the authentication step is free.
What about UPI and netbanking?
The 2D and 3D labels apply to card payments. UPI uses its own authentication inside the customer’s app, and netbanking authenticates at the bank’s login page. Neither is described as 2D or 3D.
