Any entity that facilitates online payment collection on behalf of merchants — holding or routing customer payments before settling them to merchants — falls under RBI's Payment Aggregator (PA) framework, and needs authorization before it can lawfully operate. Payment Gateways (PGs), which provide only the technology infrastructure without handling funds, are treated differently and generally don't need this authorization — but the line between the two is often blurrier in practice than fintech founders assume, and getting the classification wrong is a genuine regulatory risk, not a technicality.
Payment Aggregator vs Payment Gateway — Why the Distinction Matters
A Payment Gateway is purely a technology provider — it routes transaction data between the merchant, the customer's bank, and the card network, but funds never pass through or are held by the gateway itself.
A Payment Aggregator actually receives customer payments into an escrow arrangement and settles them to merchants — meaning it has custody, even briefly, of customer funds. Any business model where funds are pooled before merchant settlement — whether marketed as a 'payment gateway,' a 'collections platform,' or a 'checkout solution' — is functionally a Payment Aggregator in RBI's eyes if it holds funds in this way, regardless of what the business calls itself.
Key Requirements Under the PA-PG Framework
Net worth requirements:
- New PAs need to demonstrate a minimum net worth (currently ₹15 crore at the time of application, rising to ₹25 crore by a specified subsequent date) — a threshold that has genuinely disqualified several early-stage fintechs from continuing to operate as unauthorized PAs, forcing a partnership model with an already-authorized PA instead.
Escrow account requirements:
- Customer funds must be maintained in a designated escrow account with a scheduled commercial bank, with strict rules on the timing of debits and credits — merchant settlement must happen within a prescribed period, and funds cannot be commingled with the PA's own operational funds under any circumstances.
Governance and security requirements:
- Board-approved information security policy, including specific standards for data storage (customer card data storage is prohibited except under RBI's tokenization framework)
- Baseline technology recommendations around PCI-DSS compliance for card transaction handling
- A grievance redressal mechanism specifically for payment disputes, distinct from general customer support
KYC and merchant onboarding:
- PAs are required to conduct merchant due diligence — verifying the legitimacy of merchants being onboarded, monitoring for suspicious transaction patterns, and maintaining documentation that satisfies RBI's expectations on this front, since PAs are treated as having a gatekeeping role against payment fraud, not just a processing role.
Licensing Process Checklist
- Confirm classification — genuinely assess whether the business model constitutes a Payment Aggregator (fund custody) or Payment Gateway (technology only); this decision should be documented with legal and regulatory advice, not assumed.
- Build net worth to the prescribed threshold before applying, since RBI will not process an application from an entity below the minimum net worth requirement.
- Set up escrow banking arrangements with a scheduled commercial bank, with the specific account structure RBI's guidelines prescribe.
- Prepare the application to RBI with business plan, governance documentation, information security policy, and promoter/director fit-and-proper documentation.
- Build compliance infrastructure before go-live, not after authorization — merchant KYC processes, transaction monitoring, and grievance redressal systems need to be operational from day one of processing payments, not built retroactively once volumes pick up.
This is a genuine regulatory approvals exercise from the outset — the net worth certification, escrow structuring, and RBI application documentation all need coordinated preparation, not a checklist completed department by department in isolation.
Common Pitfalls for Early-Stage Fintechs
- Launching a 'payment gateway' that functionally holds funds, only to be flagged during a later funding round's due diligence as an unauthorized PA — a serious issue that can delay or derail a fundraise entirely.
- Underestimating the net worth timeline — building to ₹15 crore net worth takes real capital planning, and founders who assume this can be arranged quickly once the product is ready often find it's the actual bottleneck to launch.
- Treating escrow account structuring as a banking formality rather than a specific regulatory requirement with strict debit/credit timing rules that need to be built into the product's settlement logic from day one.
- Under-resourcing merchant due diligence, which becomes a genuine liability if the platform is later found to have processed transactions for a fraudulent or non-compliant merchant without adequate onboarding checks.
For any fintech building a checkout, marketplace, or collections product, the PA-PG classification question needs to be settled early — ideally before the product architecture is finalized — since retrofitting escrow compliance and net worth requirements onto a live platform is a materially harder problem than building for it from the start.
Perfect Accounting advises fintechs on PA-PG classification, net worth planning, and RBI application preparation, alongside the ongoing regulatory reporting once authorized.