Strong customer authentication verifies a payer through multiple independent factors. For an Indian merchant, the practical question is: which authentication does my payment flow support, and what additional security layers are available for a high-risk transaction?<\/p>\n
Razorpay documents 3DS2 for international card payments, alongside separately scoped domestic checkout features, tokenised saved cards and fraud controls. Eligible merchants can also request Address Verification System (AVS) for supported international cards. Each capability serves a different purpose, and availability depends on the card, issuer, integration and account settings.<\/p>\n
This guide explains Razorpay’s domestic and international card flows, who controls authentication, and how merchants can combine payment security with a sensible fulfilment policy. Use the comparison table and implementation checklist to identify your supported route. A successful authentication, a bank’s payment approval and your decision to release an order are separate events. Understanding those boundaries helps you assess a gateway’s security capabilities without assuming that every feature applies to every transaction.<\/p>\n
Strong customer authentication combines independent ways to verify a payer, such as possession, knowledge or an inherence factor. For Indian card payments, interpret the term alongside RBI authentication requirements and the actual issuer-supported payment flow. A protocol name alone does not establish regulatory compliance for every transaction.<\/p>\n
Two-factor authentication (2FA) describes using two distinct factors. Additional factor of authentication (AFA) describes an extra verification factor. Strong customer authentication (SCA) is often used in discussions of European payment rules, but an Indian merchant must assess the Indian requirements relevant to its transaction.<\/p>\n
EMV 3-D Secure (3DS) is a protocol for exchanging information and authenticating card-not-present payments. An OTP can be part of a challenge; it is not the definition of 3DS. For a broader terminology overview, read what strong customer authentication means<\/a>.<\/p>\n The RBI Authentication Directions, 2025 set 1 April 2026 as the general compliance date. Domestic digital payments require at least two distinct authentication factors unless exempted; for transactions other than card-present payments, at least one factor must be dynamically created or proven. Issuers may apply additional risk-based checks.<\/p>\n Section 10 uses a specific cross-border definition: an Indian-issued card paying a merchant acquired overseas. By 1 October 2026, section 10.1 required issuer validation mechanisms for non-recurring cross-border CNP transactions when an overseas merchant or acquirer requests authentication. Section 10.2 separately required an issuer risk-based mechanism for all cross-border CNP transactions. These provisions do not describe every foreign-issued card accepted by an Indian merchant.<\/p>\n Did You Know?<\/strong> The RBI directions distinguish domestic authentication rules from specific outbound cross-border card requirements. The card’s issuer and the merchant’s acquiring route both matter.<\/p><\/blockquote>\n Card security involves several participants. The merchant initiates the purchase, Razorpay provides the integrated payment experience, and the issuer evaluates the cardholder and payment. The merchant then uses the verified result and its own risk policy to decide whether an order should be fulfilled.<\/p>\n Four decisions in a card payment<\/strong><\/p>\n An Access Control Server (ACS) supports the issuer’s 3DS authentication decisions. The issuing bank can evaluate available transaction information and, when needed, ask the customer to complete a challenge. A gateway’s bank-facing ACS capability should not be interpreted as a merchant switch that forces every issuer to follow the same journey.<\/p>\n Razorpay connects your integration to supported payment flows and returns payment information. Your application still needs server-side checks, appropriate capture handling and an order policy. A high-value order with an unusual delivery request may warrant merchant review even when the cardholder completed authentication.<\/p>\n Pro-Tip:<\/strong> Track authentication failures, issuer declines and merchant review decisions separately. Each points to a different investigation and avoids labelling every unsuccessful order an OTP problem.<\/p><\/blockquote>\n For domestic card payments, your server creates an order, the customer chooses a card and completes the supported issuer-authentication flow, and your server verifies the resulting payment state before fulfilment. The exact screens and factors depend on the integration, card and issuer.<\/p>\n Use Razorpay Payment Gateway<\/a> with the relevant Standard Checkout integration steps<\/a>. Keep the order identifier and amount tied to your server’s records rather than trusting browser-submitted values.<\/p>\n The Native OTP documentation<\/a> belongs to Razorpay Optimizer and describes a supported flow with its own network and integration conditions. It should not be assumed to apply to every Payment Gateway account. Razorpay also describes inline RuPay OTP<\/a> for eligible flows. Check the applicable integration and issuer coverage before designing the customer journey.<\/p>\n An inline OTP experience changes where a customer completes a supported challenge. It does not remove the issuer’s authentication responsibilities or guarantee that every card will complete payment.<\/p>\n Razorpay’s 3DS2 documentation<\/a> covers international card payments. It explains issuer risk assessment and the frictionless or challenge journey. International payments must be enabled for the merchant, and implementation requirements depend on the checkout channel.<\/p>\n The documented browser flow is available with Standard and Custom Checkout without additional integration for that browser 3DS2 experience. Mobile app SDK integrations require the support route described in the documentation; server-to-server integrations have separate implementation guidance. Confirm the supported channel before transferring assumptions from a browser checkout into an app.<\/p>\n In a frictionless 3DS flow, the issuer can evaluate the authentication request without presenting an additional interactive challenge. A challenge flow asks the customer to complete an issuer-supported action. As EMVCo explains<\/a>, the protocol supports these different authentication experiences. An absent OTP screen does not by itself prove that a payment bypassed 3DS.<\/p>\n Non-3DS international payments<\/a> require an active KYC-verified account, international payments enablement and Risk team review of the request. Approval is account-specific. This route processes cards without second-factor authentication and carries higher fraud and chargeback risk. The documentation assigns liability for the described fraud or service-related chargebacks to the seller. Review it alongside your current merchant agreement before requesting enablement.<\/p>\n Did You Know?<\/strong> Frictionless 3DS and non-3DS can both complete without an OTP screen, but they represent different authentication routes.<\/p><\/blockquote>\n Start with Razorpay Payment Gateway<\/a> for your checkout integration and review Razorpay International Payments<\/a> when accepting overseas-issued cards. Match the authentication route to your customers, add eligible controls where useful, and verify the final payment before fulfilment.<\/p>\n Review the right card payment flow for your business.<\/strong><\/a><\/p>\n The appropriate flow depends on the card and transaction route. Use this comparison to scope an implementation discussion, then check your account’s enabled features and the relevant documentation.<\/p>\n On smaller screens, scroll the table horizontally.<\/em><\/p>\nWhat the RBI Directions Say About Domestic and Cross-Border Payments<\/h3>\n
Who Controls Authentication, Approval and Fraud Review?<\/h2>\n
\nCreate the order and start the supported Razorpay flow.<\/div>\n
\nFor 3DS, the issuer evaluates the request through its ACS: frictionless outcome or customer challenge.<\/div>\n
\nThe issuer approves or declines. Successful authentication does not guarantee approval.<\/div>\n
\nVerify payment and capture status on the server, then apply the order review policy.<\/div>\n<\/div>The Issuer and Its Access Control Server<\/h3>\n
The Gateway and the Merchant<\/h3>\n
How Razorpay’s Domestic Card Payment Flow Works<\/h2>\n
The Merchant and Customer Journey<\/h3>\n
\n
Native OTP Is a Scoped Checkout Experience<\/h3>\n
How Razorpay’s International Card Payment Flow Works<\/h2>\n
Browser, App SDK and Server-to-Server Routes<\/h3>\n
Frictionless and Challenge Flows<\/h3>\n
Non-3DS Is a Separate, Risk-Reviewed Route<\/h3>\n
Choose the Right Razorpay Card Flow for Your Business<\/h2>\n
Domestic and International Card Flows Compared<\/h2>\n