RBI's Payment Aggregator Directions, 2025 replaced the 2020 guidelines, and the circulars that followed them, with one consolidated rulebook. If your platform ever touches other people's money before it reaches its final destination, whether through a payout wallet, a dynamic QR at a counter, or a marketplace checkout, this is the regulation that decides whether you need a licence, a licensed partner behind you, or neither.
What the Directions replaced, and when they took effect
RBI issued the Payment Aggregator Directions, 2025 on 15 September 2025 (press release), consolidating the 2020 PA/PG guidelines, the amendments that followed, and a 2023 cross-border circular into a single Master Direction, effective on issue. If a compliance document you hold still cites only the March 2020 guidelines, treat it as out of date and read it alongside this Direction, not instead of it.
PA-P, PA-O, PA-CB and the payment-gateway carve-out
The Directions sort activity into three categories:
| Category | Covers |
|---|---|
| PA-P | Transactions where the acceptance device and the payment instrument are physically present in close proximity |
| PA-O | Transactions where the acceptance device and the payment instrument are not in close proximity |
| PA-CB | Cross-border payment aggregation |
A payment gateway, defined as one that works without any involvement in handling of funds, needs no licence under these Directions at all. Whether software ever touches the money, or only passes payment instructions through, is the single biggest fork in the road for anyone building payment software in India.
Net worth requirements, and a deadline that has already passed
Existing PA-P-only entities had to apply for authorisation by 31 December 2025, or wind up by 28 February 2026; both dates have now passed. The net worth bar is ₹15 crore at the time of application, rising to ₹25 crore by the end of the third year. If your platform runs in-person aggregation and did neither, take legal advice now.
Escrow debits: why an escrow account is not a general payout wallet
Under the Directions, an escrow account may be debited only for a small, fixed set of purposes:
Merchant settlement
Paying a merchant for a completed transaction
Refunds
Returning funds to a payer
A directed third-party payment
Only on the direction of a merchant with turnover above ₹40 lakh, and only where that third party is the payee the payer was actually dealing with
There is no general-purpose debit for "pay out to anyone the platform decides." A payout feature that pulls from a PA escrow account for an unrelated disbursal, such as a cashback, a referral reward or a vendor payment unconnected to the original transaction, sits outside what the Directions allow that escrow to fund.
Small-merchant KYC, and CKYCR as a secondary detail
Merchants with turnover of ₹40 lakh or less get a lighter KYC path: PAN or Form 60, contact-point verification and one Officially Valid Document.
A secondary summary of the Directions (IndiaCorpLaw) reports that the Central KYC Registry (CKYCR) is now the main reference point for merchant KYC, and that payment aggregators may not run marketplaces themselves. Treat both points as reported rather than confirmed against the primary text, and check them with your legal adviser before relying on them.
What this means for payout platforms and dynamic QR collection
The following is our own reading of how these categories apply to common product shapes, not a restatement of the Direction's own text. Confirm any of it with your legal adviser before relying on it.
- A payout platform that pays only from a business's own current account is not pooling anyone else's money, so it sits outside PA-P/PA-O entirely; it is software running on a bank's own payout product.
- A payout platform that pools funds belonging to more than one business before disbursing them is doing payment aggregation, and needs an authorised aggregator behind it, or must hold the licence itself.
- A dynamic QR carrying the merchant's own bank UPI ID moves money directly to the merchant. The software showing the QR never handles the funds, which points to a technology role rather than aggregation.
- A dynamic QR that settles into a pooled account first, with the platform crediting the merchant later, is PA-P if presented at a physical counter, or PA-O if presented online.
Marketplaces, white-label buyers and the technology-provider route
A marketplace that collects payment on behalf of many sellers before paying each of them is a textbook payment-aggregation flow, and the secondary summary above suggests aggregators may not run marketplaces themselves. In practice a marketplace typically needs its own aggregator relationship, or an authorised aggregator as its checkout provider, rather than trying to be the aggregator.
For a white-label buyer, the practical question is the same one as for any other Payonclick client: does this build pool money belonging to more than one business, or does every rupee belong to the client running it? A white-label platform is software, handed over with source code on final payment; it does not come bundled with a payment-aggregator arrangement, and the client signs its own provider contracts and carries its own regulatory responsibilities. Where a build needs pooled-fund payouts or QR collection into a pooled account, position it as running on top of the client's own aggregator relationship, as the technology partner, not as a substitute for the arrangement itself.