How to Choose a Secure Payment Gateway in India: 12-Point Security and Compliance Checklist (2026)

Most merchants compare payment gateways on pricing, payment methods and settlement speed. Security usually gets one line in the sales call, often “we are PCI compliant”, and nobody asks for proof. That is a gap, because the gateway you choose decides where your customers’ card data sits, who holds your money before settlement and how quickly you hear about an incident.

This checklist gives you 12 checks to run on any Indian payment gateway or payment aggregator before you sign. For each one it sets out what to ask, what evidence to request and what a weak answer looks like. A scoring table you can copy and a list of common red flags follow at the end.

Quick answer: To choose a secure payment gateway in India, confirm the provider is authorised by RBI as a payment aggregator (or that your funds sit with one), get its current PCI DSS Attestation of Compliance, and check that it supports card tokenisation, 3D Secure 2, usable fraud controls, signed webhooks, rotatable API keys and dashboard two-factor authentication with role-based access. Then confirm payment data is stored in India, a data processing agreement is ready for the DPDP Act, merchant funds sit in an escrow account with written settlement timelines, and dispute and incident support is in the contract.

Why should merchants check a gateway’s security before signing?

RBI regulates payment aggregators, not merchants. But the Reserve Bank of India (Regulation of Payment Aggregators) Directions, 2025 push several duties down the chain. Aggregators must make sure merchant infrastructure follows PCI DSS and PCI SSF, customer card credentials must not be stored on any database or server the merchant can access, and merchants are assessed for baseline security at onboarding.

Switching gateways later is also expensive: checkout, saved cards, mandates and reconciliation all move. OurRBI payment aggregator guidelines checklistcovers the aggregator’s own obligations; this guide is the merchant’s side of the same rules.

What are the 12 security and compliance checks?

1. Is the provider authorised by RBI as a payment aggregator?

A non-bank that handles merchant funds needs authorisation under Section 7 of the Payment and Settlement Systems Act, 2007. Banks do not need separate authorisation. A pure payment gateway that only provides technology, and never touches the money, sits outside the directions.

To check, use two RBI pages. The list of entities granted a Certificate of Authorisation (published on RBI’s Publications page, last updated 16 October 2026) has a payment aggregator section. The status-of-applications page splits applicants into online (PA-O), cross-border (PA-CB) and physical (PA-P) tables. RBI states that in-principle authorisation is not authorisation, and new applicants cannot start operating until they receive it.

Ask for the exact legal entity you will contract with and its category. If the brand is a technology layer, ask which authorised aggregator or bank holds your funds.

2. Can it show a PCI DSS Level 1 Attestation of Compliance?

A provider that stores, processes or transmits card data for you is a third-party service provider under PCI DSS. Visa treats providers handling more than 300,000 Visa transactions a year as Level 1, which means an annual assessment by a Qualified Security Assessor (QSA) and quarterly scans by an Approved Scanning Vendor.

Request the service provider Attestation of Compliance (AOC), signed by the provider and the QSA, completed within the last 12 months, with the services you will use listed in scope. Also ask for a responsibility matrix. PCI DSS requirement 12.8 expects you to monitor each provider’s compliance status at least once a year and record which requirements it manages for you. A badge on a website is not evidence. Our guide toPCI DSS certification in Indiaexplains how assessments work.

3. Does it support card tokenisation under RBI rules?

Since 1 October 2022, only card issuers and card networks may store actual card data. Everyone else in the chain may keep only the last four digits and the issuer name for tracking and reconciliation. Tokenising a card requires explicit customer consent and AFA validation by the issuer.

Ask which card networks the gateway supports for card-on-file tokens, how it handles reissued cards and deleted tokens, and whether tokens can move if you change provider. The evidence is integration documentation showing your servers receive a token reference, never a card number. See our guide tosaved-card payments and tokenisation in India.

4. Does it support 3D Secure 2 and RBI’s authentication directions?

RBI’s Authentication Mechanisms for Digital Payment Transactions Directions, 2025 have applied since 1 April 2026. They require two factors for domestic digital payments unless exempt, let issuers add risk-based checks and allow factors beyond SMS OTP. The aggregator directions also prohibit offering ATM PIN as a factor for card-not-present payments.

Ask whether the gateway sends the full 3D Secure 2 data set, which alternative methods such as passkeys or biometric approvals it can present, and whether it returns the authentication result and ECI value for each payment. Our explainer on theRBI authentication directionscovers what changed.

5. What fraud tools are included, and can you see how they work?

Every gateway claims a fraud engine. Ask what it actually does: configurable rules (velocity, amount, geography, card BIN), device and IP signals, a risk score per payment, blocklists, manual review queues and alerts for card-testing spikes.

Ask which controls are in your plan, whether you can tune rules yourself and whether risk scores and decline reasons come back through the API. An engine you cannot see into is hard to tune.

6. Are webhooks signed and verifiable?

Webhooks tell your system that a payment succeeded, failed or was refunded. If they are not signed, anyone who finds your endpoint can post a fake “payment captured” event and release goods. A secure gateway signs each webhook with a shared secret, usually HMAC-SHA256, so your server can verify it before acting.

Ask how webhooks are signed, whether each event carries a unique ID for de-duplication and how secrets are rotated.Razorpay’s webhook validation guideshows what good documentation looks like: a signature header, a per-webhook secret, an instruction to verify the raw request body and an event ID header for duplicates. Ourpayment API and webhook securityguide covers the receiving side.

7. How are API keys issued, scoped and rotated?

API keys can create payments, issue refunds and read customer data. Look for separate test and live keys, the ability to regenerate keys from the dashboard without downtime, control over which users can view or create keys, and IP allowlisting for server-to-server calls. Agencies and plugins should connect through a partner or OAuth mechanism, not your shared secret.

Evidence is the documentation and a dashboard demo. Be cautious if keys are sent by email, cannot be rotated, or if the integration needs a secret key in browser or app code.

8. Does the dashboard enforce 2FA and role-based access?

Dashboard access can issue refunds, change the settlement bank account and export customer data. Ask whether two-factor authentication can be enforced for every user, whether each person gets their own login, which predefined and custom roles exist, whether refunds and bank changes need separate permissions, and whether an audit log records who did what.

A provider that encourages one shared admin login is a red flag. Our guide topayment gateway dashboard securityincludes a permission matrix you can adapt.

9. Is payment data stored only in India?

RBI’s circular of 6 April 2018 on storage of payment system data requires payment system providers to store the entire data relating to payment systems only in India. RBI’s FAQ allows processing abroad, provided the data is deleted there and brought back to India within one business day or 24 hours of processing, whichever is earlier. Compliance is checked through a System Audit Report by a CERT-In empanelled auditor.

Ask where transaction data, logs and backups are stored, which cloud regions are used, and whether any tool processes data outside India, such as fraud scoring or support software. Get the answer in writing.

10. Is it ready for the DPDP Act?

The Digital Personal Data Protection Rules, 2025 were notified in November 2025 with a phased start. Most obligations for data fiduciaries, including security safeguards, breach reporting and contracts with data processors, apply from May 2027. As a merchant, you are usually the data fiduciary for your customers. The gateway may process data on your behalf and also hold some data in its own right for KYC and regulatory purposes.

Ask for a data processing agreement, the provider’s breach notification commitment to you, its retention and deletion policy and its sub-processor list. Our guide to theDPDP Act and payment datacovers the merchant’s side.

11. How are settlement and escrow handled?

Non-bank aggregators must keep merchant funds in a separate escrow account with a scheduled commercial bank. The day-end balance cannot fall below the amount owed to merchants but not yet settled. The aggregator-merchant agreement must state settlement timelines transparently, and refunds and reversals normally route back through escrow.

Ask for the standard settlement cycle and the cost of faster settlement, the conditions for holds or rolling reserves, how refunds and chargebacks are deducted, and a sample settlement report. If the provider cannot say where your money sits between capture and payout, stop there.

12. What dispute and incident support will you get?

The aggregator directions require a dispute resolution mechanism with refund timelines, adherence to RBI’s turnaround times for failed transactions, and a grievance officer and escalation matrix displayed on the provider’s website. Security incidents and card data breaches must be reported to RBI, and CERT-In’s 2022 directions require cyber incidents to be reported within 6 hours of noticing them.

Ask how chargebacks are notified and contested, what evidence deadlines apply, who your named contact is, and how quickly you will be told about an incident affecting your account or customers. Get that last commitment written into the agreement.

Scoring table you can copy

Score each check 2 if the provider supplies documentary evidence, 1 for a verbal or partial answer and 0 for no answer. Treat a 0 on checks 1, 2, 3, 9 or 11 as a reason not to sign.

What are the most common red flags?

A few warning signs show up again and again in gateway evaluations:

• No AOC, or only a “PCI certified” logo. An AOC that is more than 12 months old, or that does not cover the product you will use, is not evidence either.
• Shared logins. A sales or onboarding team that sets up one admin account for the whole business, or does not support enforced 2FA.
• Card data passed to merchant servers. Any integration where raw card numbers touch your backend puts you in a much larger PCI DSS scope and conflicts with RBI’s rule on merchant-accessible storage.
• Unclear escrow. Funds collected into an account the provider cannot clearly describe, or settlement timelines missing from the agreement.
• Authorisation confusion. A brand that cannot tell you which RBI-authorised entity holds your money.
• Unsigned webhooks or keys that cannot be rotated.

Frequently asked questions

1. Does every payment gateway in India need RBI authorisation?

Non-bank payment aggregators that handle merchant funds need authorisation under the Payment and Settlement Systems Act. Banks do not need separate authorisation, and pure technology gateways that never handle funds fall outside the 2025 directions, though RBI encourages them to follow the security baseline.

2. What is a PCI DSS Attestation of Compliance?

An AOC is the formal summary of a PCI DSS assessment, signed by the assessed company and, for Level 1 service providers, by the QSA. It names the services in scope and the assessment date, which is why it is more useful than a certificate or logo.

3. Can I store card details if my gateway is PCI DSS compliant?

No. RBI’s tokenisation rules allow only card issuers and card networks to store actual card data. Merchants may keep the last four digits and the issuer name, and should use the gateway’s tokenisation for saved cards.

4. How do I check whether a gateway is on RBI’s authorised list?

Search RBI’s list of entities granted a Certificate of Authorisation under the Payment and Settlement Systems Act and look in the payment aggregator section. Then check the status-of-applications page for the entity’s category and remarks.

5. Does the DPDP Act apply to payment gateways?

Yes. Gateways handle personal data and will have obligations as data fiduciaries or processors depending on the data. Most substantive duties apply from May 2027, so ask for a data processing agreement now.

6. What is an escrow account in payment aggregation?

It is a separate account with a scheduled commercial bank where a non-bank aggregator holds customer payments before settling them to merchants. RBI restricts which credits and debits are allowed, so merchant money is kept apart from the aggregator’s own funds.

7. How often should I re-check my gateway?

At least once a year, when the provider’s PCI DSS AOC is renewed, and sooner if its entity or RBI status changes.