Payment Aggregators vs. Payment Gateways
| Type | Role | Regulation |
|---|
| Payment Aggregator (PA) | Handles customer funds, manages merchant settlements | Direct RBI regulation, authorization required |
| Payment Gateway (PG) | Technology provider, transmits transaction data | Encouraged to adopt security standards voluntarily |
Payment Aggregators need to maintain a minimum net worth of ₹15 crore at application, rising to ₹25 crore by the third year. They need escrow accounts, nodal officers, and annual security audits by CERT-In empanelled auditors. Payment Gateways don't have the same regulatory burden. But they're expected to follow security standards. And merchants expect it too.
Why PCI DSS Matters for Payment Gateways
It's the Price of Doing Business: If you run a payment gateway, PCI DSS compliance is non-negotiable. Any business that stores, processes, or moves cardholder data has to follow the rules. That covers gateways, processors, cloud providers hosting payment environments, and any third-party vendors supporting payment systems.
Even if you outsource payment processing, you're still on the hook. Under PCI DSS v4.0.1, merchants using SAQ A must certify that their "site" is not susceptible to attacks from scripts. The word "site" expands the scope — you're responsible for your entire website, not just the payment components.
What Happens If You Don't Comply: Non-compliance can trigger serious consequences:
- Fines from $5,000 to $100,000 per month.
- Integration rejection by acquiring banks.
- Frozen settlement funds.
- Penalties under the PMLA and Payment and Settlement Systems Act, 2007 (up to ₹1 crore).
- Loss of merchant trust and business.
Security and Trust: PCI DSS complianceisn't just about checking regulatory boxes. It's a signal to your customers that you take their data seriously. Merchants want to work with payment gateways that take security seriously. A breach destroys trust. Customers leave. Partners walk away. News coverage amplifies everything.
What's Changed with PCI DSS v4.0.1?
The transition to v4.0.1 is the biggest shift in PCI DSS history. Here are the key changes that affect payment gateways.
The Big Difference: Client-Side Security
Previously, PCI DSS focused heavily on server-side protections. v4.0.1 changes that fundamentally. The new standard emphasizes client-side security — what happens in the customer's browser.
Requirements 6.4.3 and 11.6.1 changed the game. You now have to track, approve, and keep an eye on every single script that runs on your payment pages. Why? Because of attacks like Magecart, where bad actors slip malicious JavaScript into payment pages and steal card data straight from the browser. Server-side security never detects it.
For payment gateways, this is a big deal. You're responsible for scripts across thousands of merchant websites. A mid-sized payment processor serves 5,000-20,000 merchants, each with multiple payment pages. Changes occur daily.
v3.2.1 vs. v4.0.1 Key Changes Comparison
| Area | v3.2.1 (Legacy) | v4.0.1 (Current) |
|---|
| Script Security | Server-side focus only | Client-side inventory, authorization, and monitoring required |
| Authentication | Basic MFA for admin access | Stronger MFA across all CDE access |
| Risk Assessment | Annual assessment | Targeted risk analysis for each flexible requirement |
| Encryption | TLS 1.1 acceptable | TLS 1.2 or higher is mandatory |
| Password Length | 8 characters | 12 characters minimum |
| Vulnerability Scans | Quarterly | Monthly for some e-commerce entities using SAQ A |
The Bottom Line
PCI DSS compliance for payment gateways isn't optional anymore. Between the global standard shifting to v4.0.1, RBI guidelines tightening, and client-side security becoming mandatory, you can't afford to wait.
It's not easy, sure. But it's doable. Keep your documentation in order. Track your scripts. Monitor your payment pages. Work with people who have done this before.
