Payment gateway security is the set of controls that protects payment data and transactions, including card-data handling, encryption, authentication and fraud monitoring. For an Indian merchant, the right comparison also covers PCI DSS responsibilities, RBI requirements, customer-data protection and the help available when a payment needs investigation.
This guide compares Razorpay with two anonymised alternatives, Payment Gateway A and Payment Gateway B. Start with the tables below, then use the detailed sections to check the controls, integration and support your business needs. Razorpay brings together documented checkout choices, TokenHQ, scoped risk tools, and Ray assistance; availability and responsibilities depend on your account and deployment.
A provider’s certification is evidence about an assessed service. Your business must still confirm its own validation requirements and protect the parts of the payment flow it controls.
Key Takeaways
- Razorpay documents PCI DSS Level 1 compliance. Managed checkout can reduce merchant card-data handling, while merchants remain responsible for validating their own integration and systems.
- TokenHQ supports saved-card tokenisation without merchants retaining raw card numbers. Tokenisation protects saved credentials; hosted card entry limits exposure during collection.
- Razorpay documents TLS encryption and field-level protection for personal information. These controls complement tokenisation by protecting customer data beyond card numbers.
- Razorpay provides KYC requirements by business type. Merchants should also verify RBI authorisation for the contracting legal entity and payment activity.
- Razorpay documents 3DS2 for international cards and risk tools for eligible Indian exporters. Its Risk Analytics Dashboard exposes fraud-to-sales, dispute-to-sales and risk-decline metrics.
- Ray provides WhatsApp-based payment assistance and supported account actions for eligible merchants. Dashboard tickets and documented escalation routes support issues requiring further investigation.
Razorpay vs Payment Gateway A vs Payment Gateway B: Security and Support Compared
Razorpay combines published security and shared-responsibility guidance with TokenHQ, scoped authentication and risk tools, and Ray merchant assistance. For a business comparing gateways, the practical benefit is a documented path from selecting the checkout to managing payment questions and escalation. Use the same criteria for all three providers and confirm the features available to your account.
Security, Compliance and Data Protection
| Security / compliance criterion | Razorpay | Payment Gateway A | Payment Gateway B |
|---|---|---|---|
| Provider PCI DSS evidence | Lists PCI DSS Level 1, ISO 27001:2022 and SOC 2 Type 2. These provide different assurance lenses for your review; obtain current entity- and service-specific evidence. Security evidence. | Lists PCI DSS v4.0.1 Level 1, SOC 2 Type 2 and ISO 27001, 27017 and 27018 on its enterprise offering. | Lists PCI DSS Level 1, quarterly network scans and annual third-party audits; obtain the current service-specific attestation. |
| Merchant PCI responsibility | The shared-responsibility model spells out merchant duties. On-demand S2S requires continuing merchant PCI compliance and an AOC before each annual expiry, giving teams an explicit renewal requirement. Shared responsibilities. | Hosted web checkout collects payment details on the provider page. Merchant validation still depends on the implemented card-data path and applicable PCI scope. | Separates hosted checkout, mobile SDK and iframe collection from direct API card collection; merchants collecting raw card data retain PCI obligations. |
| Card-entry architecture | Standard Checkout and hosted collection options let teams assess a managed card-entry journey. Trace where card data travels before choosing a custom or S2S integration. Payment Gateway. | Hosted web checkout uses a server-created order, browser checkout and payment-status confirmation; website-domain whitelisting is part of the documented integration. | Offers hosted checkout, mobile SDK and iframe flows that send card data to the provider, alongside a direct API option with different merchant scope. |
| Saved-card tokenisation | TokenHQ documents network-token and saved-card flows, helping teams plan repeat payments without retaining raw card numbers. Validate consent, token-requestor role, network coverage and account eligibility. TokenHQ. | Documents a network-token vault, multi-gateway token interoperability and consent with two-factor authentication for token provisioning; supports checkout and API flows. | Documents card-on-file network tokenisation for Visa, Mastercard and RuPay, alongside saved-card checkout and device-tokenisation capabilities. |
| Encryption in transit and storage | Security documentation describes HTTPS using TLS and encryption of sensitive user data. Review the controls against your actual service, stored fields and logs. Encryption controls. | Describes SSL/TLS protection for customer data in transit. Obtain service-specific evidence for encryption at rest, key management and access controls. | Describes encrypted payment payloads, AES-256 protection for stored merchant/customer records and authenticated APIs; verify scope and key-management evidence. |
| Customer data and privacy | Documents field-level PII encryption alongside privacy terms. This supports a review covering customer information as well as card data; agree access, retention, deletion and logging responsibilities. PII controls; privacy policy. | Lists ISO 27018 cloud-PII assurance on its enterprise offering. Review the privacy terms and agree retention, deletion and data-processing responsibilities. | Describes encryption of stored merchant/customer records and internal access controls. Agree contractual retention, deletion and data-processing responsibilities. |
| RBI entity and payment activity | Verify the contracting entity and payment activity against official RBI records. Review domestic and cross-border service scope separately; a security certification is not an RBI authorisation. RBI PA directions. | Advertises domestic payment-aggregator and cross-border import/export authorisations. Verify the contracting entity and licensed activity in official RBI records. | Offers a payment-aggregator service alongside its gateway. Verify the contracting entity and authorisation category rather than relying on consumer-app credentials. |
| Merchant KYC and onboarding | Business-type KYC guidance gives merchants a document checklist before review. This helps teams prepare the right evidence; approval remains subject to business eligibility and required checks. KYC documents. | Documents PAN-based business checks, consent-based CKYC, DigiLocker/Aadhaar flows and bank-account verification, with requirements varying by entity and risk review. | Its WooCommerce onboarding requires account setup, document upload and completed KYC before activation. Obtain the entity-specific document checklist from onboarding. |
| AML and continuing obligations | Onboarding approval does not end due diligence. Record the PA and merchant roles for ongoing monitoring, suspicious-activity escalation and applicable reporting, using the RBI framework. Applicable PA duties. | Activation documentation describes beneficial-owner checks and enhanced due diligence; additional documents or video verification may follow the risk review. | Completed onboarding does not waive ongoing PA due-diligence and monitoring duties. Confirm merchant information requests and suspicious-activity escalation in the PG agreement. |
| Authentication and additional checks | 3DS2 documentation specifies international-card scope and integration prerequisites, helping teams assess the intended authentication flow. Validate domestic authentication and account eligibility separately. 3DS2 scope. | Publishes international-card 3DS2 support and two-factor authentication for card-token provisioning; confirm the chosen integration and supported card flow. | Describes 3DS2 and risk-triggered additional authentication or declines for abnormal activity; confirm card, account and integration eligibility. |
| Fraud signals and screening | Security documentation describes checks for hotlisted cards and unusual transaction patterns. Treat these as screening layers alongside authentication, fulfilment checks and your own fraud operations. Risk monitoring. | Describes ML screening across domestic and international payments, device fingerprinting and behavioural biometrics, with merchant-defined rules and blacklists. | Describes device, IP/location, behavioural and transaction-velocity signals, plus automated declines or extra verification when activity appears abnormal. |
| Merchant risk visibility and controls | Risk Analytics Dashboard exposes fraud-to-sales, dispute-to-sales and risk-decline metrics plus blocking rules for Indian exporters receiving international payments. This gives eligible teams named indicators to monitor. Exporter risk dashboard. | Documents custom-rule impact analysis before activation and review of flagged transactions, including marking a payment safe or initiating a refund. | Describes velocity limits and risk-based transaction controls. Confirm which controls and reports your merchant account can inspect or configure. |
| Evidence of better security outcomes | Use the documented risk indicators to support your evaluation, then compare confirmed fraud loss, false declines and incidents on the same transaction mix. No matched cross-provider outcome ranking was established. | Rule impact and flagged-payment controls are published capabilities; comparable fraud-loss and false-decline results require a matched assessment. | Risk signals and automated checks are published capabilities; comparable fraud-loss and false-decline results require a matched assessment. |
PCI DSS evidence and tokenisation appear across all three providers. Razorpay’s documented responsibility model helps you connect those controls to the integration your team will deploy. Its TokenHQ and product-specific authentication documentation also make the prerequisites explicit, so you can plan the right payment flow and evidence review.
End-to-End Merchant Support and AI Assistance
| Merchant support stage | Razorpay | Payment Gateway A | Payment Gateway B |
|---|---|---|---|
| Onboarding and activation | Business-type KYC checklists and product/technical support routes help merchants prepare documents and integration questions together. Compliance approval remains a separate decision. Onboarding guidance. | Documents CKYC/DigiLocker-based verification and activation support; enterprise merchants are offered dedicated technical and operational account managers. | Documents KYC before activation and integration-team UAT sign-off before production credentials are shared for the API integration. |
| Developer and integration help | Integration guides, API references and Dashboard product/technical tickets provide documented routes from implementation to investigation. Select the correct environment and include transaction references. Technical help. | Provides hosted-checkout guides, APIs/SDKs and developer support; enterprise integration help includes migration and engineering assistance. | Dashboard includes Help > Need integration support; developer documentation covers backend SDKs and Android, iOS, Flutter and React Native integrations. |
| Payment status and failures | Ray provides account assistance through WhatsApp for payment questions and insights. Teams can use conversation for supported queries and tracked Dashboard tickets for unresolved investigations. Ray. | Dashboard AI answers account-specific payment queries and failure explanations; a separate WhatsApp assistant provides payment/order lookups and support help. | Merchant Dashboard shows transaction information; order-status APIs and payment-success/failure webhooks support automated status checks and investigation. |
| Refund assistance | Ray launch material describes supported refund actions through WhatsApp account assistance. Verify account access and task authorisation; initiating a refund does not guarantee when the customer bank credits it. Supported Ray actions. | Dashboard AI documents refund actions with user approval; available tasks depend on account permissions and product access. | Documents refund initiation and refund-status APIs, plus completed/failed refund webhooks, so merchant systems can track the refund lifecycle. |
| Settlements and reconciliation | Ray answers settlement questions and provides account insights through WhatsApp, giving eligible teams a conversational route to understand payment operations. Confirm supported tasks; an explanation is not a credit guarantee. Ray account assistance. | Dashboard AI describes settlement queries, reconciliation reports and approved instant-settlement actions; eligibility and charges remain product-specific. | Merchant Dashboard provides settlement and transaction reporting; use the selected reporting and support workflow to investigate unmatched amounts. |
| Disputes and evidence | Documents dispute notifications, Dashboard accept/contest actions and evidence submission against a respond-by date, giving teams an explicit case workflow. The issuing bank determines the outcome. Disputes. | A separate AI operations suite advertises dispute-response assistance alongside payment recovery and subscription dunning; confirm access and review requirements. | Obtain the PG-specific dispute notification, evidence-submission and deadline workflow during onboarding; consumer-app grievance terms are not sufficient evidence. |
| AI channel and operational scope | Ray is marketed as 24×7 WhatsApp account assistance with English/Hindi text and voice queries, payment insights and supported actions. This can suit teams managing payments from a familiar messaging channel. Ray on WhatsApp. | Offers dashboard account AI, a separately enabled WhatsApp assistant and distinct operations agents for tasks such as recovery, disputes and dunning. | Advertises AI creation of payment pages from prompts. Evaluate payment-page creation separately from account investigation, refund assistance and human support. |
| Permissions and financial actions | Ray describes a security-verification link for account actions. Review authorised access, approval steps and records for each financial task before enabling it for your operations team. Ray verification flow. | Dashboard AI documents action approvals, existing Dashboard permissions and audit trails; WhatsApp access requires a separate enablement request. | APIs use expiring client-credential access tokens; payment/refund webhooks support authentication checks. API authentication is separate from internal approval of financial actions. |
| Contact channels and availability | Dashboard tickets provide issue tracking. Chat/callback is available to selected users; published chat hours are 10 a.m.-10 p.m. on working days. Ray availability and human support hours are separate. Support access. | Enterprise offering advertises 24×7 priority support, dedicated account managers and custom SLAs; confirm the contracted tier rather than assuming universal entitlement. | Gateway marketing advertises 24/7 support and a Dashboard integration-support route. Confirm staffed channels, response commitments and account coverage. |
| Unresolved issue and escalation | After a missed committed resolution TAT/SLA, the available Dashboard escalation option provides priority handling and documented phone contact within two hours. That contact commitment is not a resolution deadline. Escalation process. | Publishes a multilevel grievance process. Formal complaint timelines and enterprise contractual SLAs should be distinguished from routine ticket-resolution times. | Confirm the PG-specific escalation owner, channel and committed turnaround in the merchant agreement; do not substitute consumer-wallet or UPI complaint timelines. |
| Support-quality evidence | Compare first useful response, resolution, reopened tickets and authorised AI task completion using the same merchant tasks. Ray and the documented ticket/escalation workflow are features to test, not measured proof of faster resolution. | AI actions, enterprise account management and priority support are published features; no matched response or resolution ranking was established. | A 24/7 availability claim and developer tools do not establish resolution speed; run the same support and task-completion assessment. |
When Is Razorpay a Strong Fit?
Razorpay brings together a documented merchant-responsibility model, TokenHQ saved-card flows, product-specific authentication guidance and tracked operational support. For Indian exporters receiving international payments, its Risk Analytics Dashboard names the fraud-to-sales, dispute-to-sales and risk-decline indicators a team can monitor. For eligible accounts, Ray adds English/Hindi text and voice assistance on WhatsApp for payment questions and supported actions. These are concrete reasons to shortlist Razorpay when those workflows match your business. The alternatives also document substantial security and AI capabilities; suitability depends on the integration, account access and support terms you will actually use.
Which Core Metrics Should You Compare?
Ask every provider for the same transaction mix and observation period: confirmed fraud loss in basis points of processed value; false declines as a share of assessed legitimate attempts; comparable reportable incidents; median and p90 first useful response and resolution times; and reopened-ticket rate. Test AI answer accuracy and authorised-action completion on the same tasks. Published capabilities alone do not establish those results, and this review does not supply a matched performance ranking.
How Should You Compare Payment Gateways on Security and Compliance?
Compare payment gateways using current compliance evidence, the actual card-data path, supported tokenisation and authentication, merchant responsibilities, and operational help. Ask what each control covers, which account or integration can use it, and what remains your responsibility. A feature name alone is not enough to assess suitability.
Security, Compliance and Data Protection Answer Different Questions
Security is about protecting systems and transactions: access control, monitoring, encryption and fraud screening. Compliance is about the obligations that apply to your entity and activity, and the evidence that demonstrates them. Data protection is about collecting, using, sharing, retaining and deleting information appropriately. A control can be good security practice without being a statutory mandate, and a compliance document does not by itself prove a control works in your deployment.
Turn Feature Claims Into Evidence Requests
Three questions convert marketing copy into something you can file:
- Can you show the service scope? Which legal entity was assessed, for which services, over which period.
- Where do card details travel? In the exact integration you plan to deploy, not in a best-case architecture diagram.
- What happens when the workflow fails? A failed payment, a refund that has not credited, a disputed transaction.
Use a three-part framework for the file you retain: evidence reviewed, integration verified, responsibilities recorded.
How Can a PCI DSS-Compliant Gateway Reduce Merchant Compliance Burden?
Razorpay’s public security documentation lists PCI DSS Level 1. For a merchant, the potential reduction in card-data handling depends on the supported checkout flow and its implementation. Review the provider’s current service evidence, then confirm your own validation requirements. Provider compliance does not automatically certify your website or business.
The Razorpay security documentation describes the provider’s published status. The PCI Security Standards Council explains that outsourcing payment processing does not remove every merchant obligation. Request current evidence for the service and legal entity you will use.
Provider Evidence Is Not a Merchant Certificate
An Attestation of Compliance records that a named entity was assessed for named services over a defined period. Your validation is a separate exercise, usually a self-assessment questionnaire or a report agreed with your acquiring bank, covering your website, systems and processes. Level 1 is a validation classification, rather than a different version of PCI DSS. Confirm the applicable classification and validation route with the relevant acquirer or payment brand.
Match the Assessment to the Real Integration
Managed card entry can reduce the cardholder data your systems handle. The exact implementation still matters. The PCI Security Standards Council’s SAQ A script-attack guidance applies specifically to merchant webpages containing an embedded payment page or form. That particular eligibility criterion does not apply in the same way to redirect-only flows or fully outsourced payment links. Confirm all eligibility criteria for your deployment and review scripts that can affect payment security.
DID YOU KNOW #1: Outsourcing payment processing never removes every merchant obligation. The split is explained in our guide to Razorpay Checkout and merchant PCI DSS responsibilities.
Tokenisation, Hosted Checkout and Hosted Fields: What Keeps Card Data Away From Your Servers?
Razorpay documents TokenHQ and managed checkout options for supported saved-card and payment flows. Tokenisation and card-entry isolation are separate design decisions. Before choosing an integration, trace where raw card details travel and confirm the exact supported option. Customising a checkout does not by itself prove that it uses isolated hosted fields.
Distinguish Card Entry From Saved-Card Tokenisation
Card entry is about the moment the customer types a card number: which party’s code renders that field, and which party’s systems receive the value. Tokenisation is about what happens afterwards, when an eligible saved credential is reused. The two can be configured independently. A token also does not mean your systems hold nothing sensitive: order records, customer names, addresses and payment references still flow to you.
For saved cards, evaluate the supported token-requestor role and network flow rather than assuming that a tokenisation label describes every integration.
Compare the Integration Models Before Choosing
Card-entry approaches and the questions merchants should resolve.
| Approach | What to evaluate | Razorpay route to assess | What must be confirmed |
|---|---|---|---|
| Provider-hosted collection destination | Whether a shared link or hosted page fits the customer journey | Payment Links or Payment Pages | Supported payment flow, account access and merchant validation |
| Managed checkout on a website or app | Who controls card entry and where details travel | Standard Checkout | Exact embedding, scripts, plugins and supported data flow |
| Isolated hosted fields | Whether sensitive inputs are controlled by the provider in isolated components | Request a documented integration-specific answer | Obtain the exact SDK, supported architecture and eligibility in writing before selecting this option |
| Custom checkout experience | The effect of custom inputs, scripts and API calls | Custom Checkout documentation plus Product review | A custom interface is not synonymous with isolated fields |
| Server-to-Server card integration | Direct processing responsibilities and account prerequisites | On-demand S2S integration | Continuing merchant PCI compliance and required AOC submissions |
The S2S documentation is explicit that the merchant can capture payment details on its own server. That is the clearest case where your obligations increase rather than reduce.
TokenHQ Supports Specific Roles and Prerequisites
TokenHQ covers the saved-card and network-token capability, including the distinction between Razorpay acting as token requestor and a business acting as its own token requestor. The business-as-requestor flow is available on demand and for PCI-compliant merchants, so do not apply its prerequisites to every Standard Checkout saved-card feature. For the documented Razorpay-as-token-requestor flow, the network activation notes specify different go-live timings. Confirm the current timing for your networks and account. If token portability matters, ask which token-requestor flow, network rules and integration prerequisites apply.
DID YOU KNOW #2: A token protects a particular payment credential or flow. It does not replace appropriate handling of names, addresses, order records or support attachments.
How Do Encryption and Customer-Data Controls Complement Tokenisation?
Tokenisation replaces a payment credential with a substitute reference; encryption protects information in its applicable transmission or storage context. A merchant should also review access, logs, retention and support data. Evaluate these controls together, because reducing card storage does not remove the need to protect other customer information.
Keep Encryption Claims Specific
Razorpay’s security documentation describes HTTPS using TLS and field-level encryption for personally identifiable information. These are specific controls you can assess alongside your own access and logging practices. Ask which services and data categories each control covers. A cipher or protocol name alone does not establish that one gateway produces better security outcomes.
Review Customer Information Beyond Card Numbers
Ask who inside your business can view full order information, what customer data enters application logs, what gets pasted into support tickets, and which retention terms apply. Razorpay’s published privacy policy describes its handling terms, though a policy is a statement of practice rather than an independent audit. The Digital Personal Data Protection Rules, 2025 have phased commencement. Map the provisions applicable to your business and service to your notice, retention and data-handling processes. Check incident reporting and contractual notification duties separately.
An illustrative scenario, not a recorded incident: a merchant removes all backend card collection, then a support agent attaches a screenshot of a full order record to a chat thread. The card data risk fell. The personal data risk did not. For technical depth, see our card and customer-data tokenisation and encryption checklist.
What Should Indian Merchants Verify About RBI, KYC and AML Compliance?
Start with the legal entity and payment activity in your agreement, then check the applicable RBI authorisation and onboarding requirements. Review merchant KYC, settlement and grievance terms separately from technical security. A gateway’s authorisation does not transfer all of your business’s compliance duties.
The governing instrument is the RBI Master Direction on Regulation of Payment Aggregators, dated 15 September 2025. A payment aggregator receives funds from customers and settles them to merchants, which is why it carries onboarding, escrow and due-diligence duties. A payment gateway in the narrow technical sense routes transaction data. Consumer payment apps, banks and verification APIs are different services again.
Match Entity, Activity and Contract
Request the contracting entity name, the relevant authorisation category, current evidence and the settlement terms. Then verify it against the RBI list of payment aggregator applications and authorisations rather than a vendor summary. Payment data storage obligations stem from RBI’s Storage of Payment System Data circular, which places responsibility on authorised payment system operators.
Merchant Onboarding Is Different From Your Customer KYC
Razorpay publishes KYC requirements by business type, showing that documentation depends on your constitution and activity. That is onboarding due diligence on you as a merchant. It is not proof that a provider offers a customer video-KYC or AML-screening API for your own users. The RBI PA directions also require ongoing monitoring against merchant business profiles and, for non-bank PAs, FIU-IND registration and applicable reporting. Ask how document re-review and unusual activity are handled. These provider duties do not replace any obligations that separately apply to your own business.
PRO-TIP #2: Ask what documents and consents are required, what can trigger a re-review, and where onboarding issues should be escalated. For the verification steps, use our guide to verifying an RBI-authorised payment aggregator.
Which Authentication and Risk Controls Matter for Higher-Risk Transactions?
Assess authentication separately from fraud monitoring. Authentication helps verify the payer; monitoring helps assess transaction risk. Razorpay’s documented 3DS2 card feature is scoped to international cards, while its Risk Analytics Dashboard is described for Indian exporters. Confirm supported channels and account availability for the transactions you actually process.
Domestic and International Card Flows Need Separate Answers
The RBI’s September 2025 authentication announcement describes additional issuer risk checks beyond minimum two-factor authentication and retains SMS OTP as an available factor. It gives 1 April 2026 as the general compliance date, subject to directions with a different date. Confirm the applicable transaction scope, exemptions and issuer responsibilities rather than applying one flow to every payment.
Keep that separate from 3DS2. Razorpay’s 3DS2 documentation describes support for international card payments, with browser and app or SDK channels differing in availability. Do not convert that into a universal domestic-card capability, and do not import European SCA rules as India’s framework. Authentication success, payment success and fraud-loss outcomes measure three different things.
Compare Monitoring, Rules and Investigation Tools
Ask each provider which suspicious-transaction signals exist, which rules you can configure, who reviews flagged transactions, and what dispute evidence the system retains. Razorpay’s Risk Analytics Dashboard is documented for Indian exporters receiving international payments, so do not assume it is enabled for every domestic account. An issuer-side authentication service is not evidence that you control that engine, and payment routing is a reliability feature, not an AML guarantee.
DID YOU KNOW #3: A successful authentication is not proof that a transaction is risk-free. Our domestic and international authentication guide sets out the scope differences.
How Does Merchant Support Work From Onboarding to Escalation?
Evaluate support across the merchant lifecycle: onboarding, integration, payment investigation, refunds, settlements, disputes and unresolved issues. Razorpay documents technical help, Dashboard tickets and escalation, while Ray offers announced WhatsApp assistance for account queries and supported actions. Check availability, permissions and human contact separately from resolution quality.
Start With Onboarding and Integration Help
Start onboarding by preparing the right documents. The business-type KYC documentation tells you what to assemble before you apply. Technical and product queries route through the documented support process. Keep two things apart: a developer troubleshooting a webhook signature is a support topic, while a compliance team’s approval of your business category is a review decision with its own timeline.
Follow the Payment Through Refunds and Settlements
Ray is presented as WhatsApp-based account assistance covering payment and settlement questions, insights, payment-link creation and supported refund actions, per Razorpay’s launch announcement. The Ray WhatsApp overview describes a security-verification link for authenticated account actions. Confirm rollout, access, permissions and available actions for your account. A status answer, a refund instruction and a final bank credit are separate events.
An illustrative scenario: a customer asks why a refund has not arrived. You retrieve the payment reference, confirm the refund was initiated and when, and tell the customer what has happened on your side. If the expected credit window has passed, you raise a Dashboard ticket with the payment ID and refund ID attached.
Keep Dispute Evidence and Escalation Visible
The disputes documentation describes notifications, Dashboard review and evidence submission, including proof of delivery and invoices, with a respond-by deadline. The issuer decides the outcome of a contested dispute. That is a workflow benefit, not a guaranteed chargeback win.
Razorpay’s published support process states that an escalation option becomes available on a ticket when its committed resolution TAT or SLA is not met, after which the case moves to a priority queue and a representative contacts you by phone within the next two hours. That is conditional contact, not a two-hour resolution promise. Live chat and callback are documented for selected users, with chat hours of 10 a.m. to 10 p.m. on working days.
Compare AI Access and Controls Fairly
Payment Gateway A documents dashboard AI account assistance, a WhatsApp merchant assistant and separate AI operations agents. Payment Gateway B publishes 24/7 support and AI payment-page creation. Evaluate the tasks, permissions and escalation route each option makes available to your account. Ray gives eligible Razorpay merchants a conversational workflow to assess alongside the Dashboard support process. The standards body’s guidance on securing AI in payment environments notes that where an AI has agency to perform actions, incident response planning must account for it.
PRO-TIP #3: Request the same demonstration from each provider: one account-specific payment query, one permitted refund action and one unresolved issue. Keep raw card details and API secrets out of chat.
What Should You Check Before Launching or Changing Your Checkout?
Work through these seven steps and keep the output of each on file.
- Record the legal entity, the payment activity and the selected integration.
- Obtain current service-specific compliance evidence and record its scope and period.
- Map the card-entry, order and payment-confirmation paths for your actual build.
- Confirm your merchant validation requirement and which controls each party owns.
- Test the permitted tokenisation, authentication and payment-status flows in the appropriate environment.
- Check authorised access, logs, support attachments and the escalation route.
- Approve launch through your own review process, and repeat after any material change.
Completing the checklist does not certify your business. It produces the records your reviewers, acquirer and auditors will ask for.
Frequently Asked Questions
Does using Razorpay automatically make my business PCI DSS compliant?
No. A provider’s attestation covers its assessed entity and services. Your business still completes its own validation, usually a self-assessment questionnaire agreed with your acquirer, covering your website, scripts and processes. See our guide to Razorpay Checkout and merchant PCI DSS responsibilities.
Are hosted fields, Standard Checkout and tokenisation the same thing?
No. Hosted fields isolate sensitive inputs inside provider-controlled components. Standard Checkout is a managed checkout experience. Tokenisation replaces a stored card credential with a reference for eligible later payments. Verify the exact integration you deploy.
What is the difference between tokenisation and encryption in payment security?
Tokenisation replaces a payment credential with a substitute reference for an eligible payment flow. Encryption protects information using keys and can protect card data as well as names, addresses and order records. Card tokenisation does not automatically protect those other records, so apply appropriate encryption, access, retention and logging controls.
What KYC and RBI evidence should I review before choosing a gateway?
Match the contracting legal entity and the payment activity against RBI’s published authorisation records, then review merchant KYC documents by business type, settlement terms and grievance routes. Start with our guide to verifying an RBI-authorised payment aggregator.
Does Razorpay support 3DS2 for domestic and international cards?
Razorpay’s current 3DS2 documentation describes support for international card payments, with browser and app channel differences. Confirm your domestic card authentication flow separately, since India’s requirements are set by RBI’s authentication directions.
