"Is the payment gateway secure?" is the question most businesses ask, and it's the wrong one to stop at. A regulated payment provider is usually the best-defended part of the chain. The weak points are at the edges: the checkout page a script can be slipped into, the dashboard login shared by four people, the webhook endpoint that believes anything sent to it, the finance inbox that receives a convincing request to change the settlement bank account.
This guide walks through the layers that protect an online payment in India, what RBI requires of payment providers, which attacks are aimed at merchants rather than providers, and the checklist of things that are genuinely your job.
The layers that protect a payment
No single control makes a payment safe. Each layer covers a different risk, and each has a clear owner.
| Layer | What protects it | Who's responsible |
|---|---|---|
| Proving it's the customer | Two-factor authentication: UPI PIN, card OTP or another second factor | The customer's bank or card issuer |
| Card details | PCI DSS, tokenisation, and RBI's ban on merchants storing card data | Everyone who handles card data; the provider and networks for tokens |
| Data in transit | Encrypted connections (HTTPS) end to end | Every party, including your website |
| The provider's systems | RBI's security and audit requirements for payment aggregators | The payment provider |
| Your checkout and servers | Secure integration, protected pages, secrets kept server-side | You |
| Your people and processes | Access control, approvals for refunds and bank changes, monitoring | You |
What RBI requires of payment aggregators
Most online businesses collect through a payment aggregator, and RBI's 2025 directions for aggregators include specific security duties. Knowing them tells you what you can expect, and what your provider will expect of you.
- A board-approved information security policy for the safety and security of the payment systems it runs.
- An annual system audit, including a cyber security audit, by auditors empanelled with CERT-In.
- Monthly reports to RBI on cyber security incidents, with root cause and preventive action.
- Compliance with RBI's data storage requirements for payment system operators, and measures to avoid storing data on infrastructure belonging to external jurisdictions.
- A baseline set of technology controls in the directions' annexure, covering security governance, access on a least-privilege basis, cryptography and forensic readiness, among others.
- Ensuring that the infrastructure of the merchants it onboards complies with security standards such as PCI DSS and PCI SSF, as applicable, with a security assessment during onboarding.
That last duty is why a provider's onboarding asks how your checkout handles card data, and why our merchant onboarding checklist includes your website's security. The directions also state plainly that customer card credentials must not be stored in the database or servers the merchant accesses.
PCI DSS, in plain terms
PCI DSS is the card industry's data security standard, maintained by the PCI Security Standards Council. It sets a baseline of technical and operational requirements to protect payment account data, and it applies to any entity that stores, processes or transmits cardholder data or sensitive authentication data, or could affect the security of the environment where that happens. That includes merchants, processors, acquirers, issuers and service providers.
The practical question for a business is how much of your environment falls inside that scope, and the answer depends mostly on your integration. If customers type card details only into your provider's hosted page or secure fields, card data never reaches your systems, and your obligations are far smaller than if your own servers receive card numbers. Our guide to payment gateway integration methods compares the options with this in mind.
Tokenisation: why merchants don't keep card numbers
Since RBI's restrictions on storing card data took effect, merchants and their payment providers can't keep customers' actual card numbers. Saved cards work through tokens instead: a substitute value issued under RBI's card-on-file tokenisation framework, usable only for that merchant and that card, which is useless to a thief who steals it from the merchant.
For a business, this removes the most valuable thing an attacker could steal from your database. Our card tokenisation guide explains how saved cards work under these rules.
Authentication: the customer's bank does the heavy lifting
Under RBI's 2025 authentication directions, digital payments must be authenticated by at least two distinct factors, and for payments where the card isn't present, at least one of them must be dynamic: unique to that transaction, like an OTP. Issuers may add risk-based checks on top. If a loss arises from a transaction processed without complying with these directions, the issuer must compensate the customer in full.
For card payments online, this happens in the 3D Secure step. Our 3D Secure guide explains how it works and why it sometimes fails.
The attacks aimed at merchants
Fraudsters rarely try to break into a regulated payment provider. They go after the business, where defences are thinner. These are the patterns to plan for:
| Attack | What happens | Defence |
|---|---|---|
| Checkout page tampering | Malicious code added to your checkout page captures what customers type or redirects them | Hosted checkout or secure fields; tight control of scripts and plugins on payment pages |
| Fake webhooks | Someone sends your server a made-up "payment successful" message to get goods for free | Verify every webhook's signature and confirm the status with the provider |
| Card testing | Bots try many small payments with stolen card numbers to see which work | Rate limits, bot protection and monitoring for bursts of small declined payments |
| Dashboard takeover | A stolen or reused password gives access to refunds, payouts or settings | Two-factor login, individual accounts, prompt removal of leavers |
| Bank detail change request | A convincing email or call asks you to change the settlement or vendor bank account | Verify through a known channel; require a second approver |
| Refund abuse | Refunds sent to accounts that never paid, by an insider or a compromised account | Refunds only to the original payment, with limits and approvals |
| Leaked API keys | Keys left in app code or a public repository are used to call your provider | Keys only on servers, separate test and live keys, rotation on exposure |
UPI collections have their own weak points
Card data is the classic concern, but UPI payments, where no card data exists, have weak points of their own, mostly about where the money is sent and how you know it arrived:
- Swapped QR codes. A printed QR code at a counter or on an invoice can be covered with someone else's. Check your displayed codes regularly, and prefer dynamic QR codes generated per sale by your billing system, which show the exact amount and your business name.
- Fake confirmations. A customer's screenshot proves nothing. Rely only on your own soundbox, merchant app, provider dashboard or bank, which a customer can't fake.
- Collection details changed in your systems. Anyone who can edit the UPI ID or bank account printed on your invoices or shown at checkout can divert payments. Treat those settings like payout bank details: restricted access and a second approver.
- Names customers see. NPCI's rules make UPI apps show the payee's bank-registered or verified name before the customer pays. Make sure that name is recognisably your business, so customers can spot a lookalike.
Your security checklist
Grouped by area, this is the work that's genuinely yours, whichever provider you use.
- Card data: never store, log or email card numbers or CVVs. Use your provider's hosted page or secure fields, and tokenised saved cards.
- Website: serve everything over HTTPS, keep your platform and plugins updated, and allow only the scripts you need on payment pages.
- Secrets: keep API keys and webhook secrets in server-side configuration, never in browser or app code, and rotate them when people with access leave.
- Webhooks: verify signatures, reject old or repeated messages, and process each event only once.
- Orders: take the amount from your server, never from the browser, and mark orders paid only on a verified webhook or status check.
- Dashboard access: one account per person, two-factor login, the least access each role needs, and same-day removal of leavers.
- Money out: maker-checker approval for refunds above a limit, payouts, and any change to bank details.
- Monitoring: alerts for spikes in declines, refunds or failed logins, and a daily look at exceptions in your reconciliation.
For webhooks specifically, our guide to payment gateway webhooks covers signature checks, retries and duplicate handling in detail.
Questions to ask your payment provider
Security is a shared responsibility, so ask your provider about its half, in writing. Our checklist for choosing a payment gateway covers the commercial questions; these are the security ones:
- Are you RBI-authorised as a payment aggregator, or a bank?
- Is your platform PCI DSS compliant, and can you share your attestation?
- Which integration methods keep card data off our systems, and do you support tokenised saved cards?
- How are webhooks signed, and how do you retry failed deliveries?
- Does your dashboard support two-factor login, individual users and role-based permissions?
- How will you tell us about a security incident that affects our account, and how fast?
If something goes wrong
Have a short plan written down before you need it:
- Contain: disable the compromised account or key, rotate secrets, and take down any tampered page.
- Tell your payment provider straight away, through its official support channel, so it can watch for fraud on your account.
- Preserve logs and evidence; don't wipe and rebuild before you know what happened.
- Check whether customers' data was exposed, and what legal and contractual duties you have to report and notify.
- Fix the cause, then review: what would have caught this sooner?
If customers report fraudulent debits connected to your business, point them to their bank and the national cyber fraud helpline 1930. Our guide to UPI fraud explains the customer's side of that process.
Frequently asked questions
Is it safe to pay through a payment gateway?
Regulated payment providers in India work under RBI's security, audit and data-storage requirements, card details are protected by PCI DSS and tokenisation, and payments need two-factor authentication from your bank. The bigger risks are fake websites and scams that trick you into approving a payment, so check you're on the real site before paying.
Does my business need PCI DSS compliance?
If you accept cards, PCI DSS is relevant, but how much of it applies depends on whether card data reaches your systems. With a hosted checkout or your provider's secure fields, your obligations are much smaller than with a direct card API. Your payment provider will tell you what it needs from you.
Can a merchant store customers' card numbers?
No. RBI's rules don't allow merchants to store actual card data, and its payment aggregator directions say card credentials must not be stored on the merchant's database or servers. Saved cards work through tokens.
What security does RBI require of payment aggregators?
Among other things, a board-approved information security policy, an annual system and cyber security audit by CERT-In empanelled auditors, monthly cyber incident reporting to RBI, compliance with payment data storage rules, and checks that their merchants' infrastructure meets standards such as PCI DSS.
Official sources
- RBI — Reserve Bank of India (Regulation of Payment Aggregators) Directions, 2025 (15 Sep 2025)Merchant infrastructure compliant with PCI-DSS and PCI-SSF (9(a)); board-approved information security policy (9(b)); data storage (9(c)); annual system and cyber security audit by CERT-In empanelled auditors (9(d)); Annexure 1 baseline controls, monthly incident reports (1.3), onboarding security assessment (1.4), no card credentials on merchant servers (2.1).
- PCI Security Standards Council — PCI DSSBaseline technical and operational requirements to protect payment account data; applies to entities that store, process or transmit cardholder data or could impact the cardholder data environment.
- RBI — Restriction on Storage of Actual Card Data [i.e. Card-on-File (CoF)] (24 Jun 2022)
- RBI — Tokenisation – Card Transactions: Permitting Card-on-File Tokenisation (CoFT) Services (7 Sep 2021)
- RBI — Authentication mechanisms for digital payment transactions Directions, 2025At least two factors, one dynamic for card-not-present payments; risk-based checks; issuer compensates in full for non-compliant transactions.
- NPCI — UPI Consolidated Circular, Version 1.0, NPCI/UPI/CC/01 (18 Sep 2026)Payee details and bank-registered or verified brand names shown before the customer pays (2.6, 2.13–2.15).
Last reviewed . Examples, amounts and screens marked illustrative are not LILPE figures.
