A non-bank Payment Aggregator in India requires RBI authorisation under the Payment and Settlement Systems Act framework and the RBI (Regulation of Payment Aggregators) Directions, 2025. The applicant must be an Indian company, have PA activity in its Memorandum, maintain at least ₹15 crore net worth at application and reach ₹25 crore by the end of the third financial year after authorisation. Approval also depends on fit-and-proper management, merchant KYC, escrow controls, information security, FIU-IND obligations and the strength of the proposed business and compliance framework.
Payment Aggregator License – 2026–27 at a Glance
| Point | Current Position |
|---|---|
| Regulator | Reserve Bank of India (RBI) |
| Core framework | RBI (Regulation of Payment Aggregators) Directions, 2025 |
| Applicant type | Non-bank company incorporated in India |
| Application route | RBI PRAVAAH online portal |
| Minimum net worth at application | ₹15 crore |
| Net worth after authorisation | ₹25 crore by end of third financial year; maintained thereafter |
| Main categories | PA-Online (PA-O), PA-Physical (PA-P), PA-Cross Border (PA-CB) |
| Merchant due diligence | KYC / CDD under RBI KYC framework; CKYCR-first approach where available |
| Funds handling | Separate escrow account with a Scheduled Commercial Bank for domestic PA business |
| AML reporting | FIU-IND registration and reporting obligations for non-bank PAs |
| Cyber controls | RBI cyber-resilience directions + annual system/cyber audit |
| Approval timeline | No fixed guaranteed statutory timeline; depends on completeness and RBI examination |
The governing source is the RBI Master Direction on Regulation of Payment Aggregators, 2025. Applications are filed through the RBI PRAVAAH portal.
What Is a Payment Aggregator?
A Payment Aggregator (PA) is an entity that enables customers to make payments to merchants through one or more payment channels and then settles the collected money to those merchants. The defining regulatory feature is not merely providing software. A PA enters the money flow: it aggregates customer funds for merchants and later settles those funds according to the agreed cycle.
The 2025 RBI framework recognises three categories. PA-Online covers transactions where the acceptance device and payment instrument are not in physical proximity. PA-Physical covers proximity or face-to-face payment acceptance. PA-Cross Border covers permitted cross-border current-account payments through e-commerce for onboarded merchants.
This distinction matters because a pure Payment Gateway provides technology to route or process a payment without handling funds. A gateway does not automatically become a Payment Aggregator simply because it provides checkout APIs, routing, tokenisation support or transaction technology.
Payment Aggregator vs Payment Gateway
| Feature | Payment Aggregator | Payment Gateway |
|---|---|---|
| Handles merchant funds | Yes, subject to escrow and settlement rules | No |
| RBI PA authorisation | Required for a non-bank PA | PG is outside the PA Master Direction when it does not handle funds |
| Merchant onboarding | Direct regulatory responsibility applies | Usually technology/service-provider role |
| Escrow account | Required for non-bank PA | Not applicable merely for PG activity |
| Regulatory focus | Funds flow, KYC, AML, settlement, cyber security, governance | Technology, outsourcing and information-security controls under applicable arrangements |
Who Needs a Payment Aggregator License?
A non-bank entity that intends to operate as a Payment Aggregator must obtain RBI authorisation. The applicant must be a company incorporated in India under the Companies Act, 2013 and its Memorandum of Association should expressly cover the proposed PA activity.
- Fintech companies collecting customer payments and settling those funds to multiple merchants.
- Platforms offering merchant payment acceptance where customer funds are pooled before settlement.
- Businesses building online merchant aggregation (PA-O), physical point-of-sale aggregation (PA-P), or qualifying cross-border aggregation (PA-CB).
- Existing regulated financial-sector entities proposing PA activity, subject to the required No Objection Certificate from the relevant regulator before the RBI application.
A bank does not need a separate PA authorisation under this Master Direction. A non-bank applicant, however, should not treat company incorporation, payment technology readiness or a bank partnership as a substitute for RBI authorisation.
Payment Aggregator License Eligibility
| Requirement | Practical Meaning |
|---|---|
| Indian company | Applicant must be incorporated under the Companies Act, 2013. |
| Correct object clause | MoA must cover Payment Aggregator activity. |
| Net worth | At least ₹15 crore at application; ₹25 crore by end of third financial year after authorisation. |
| Fit and proper | Promoters and directors must demonstrate integrity, sound reputation and financial soundness. |
| Business readiness | Clear PA model, payment flow, merchant segments, settlement model and risk controls. |
| KYC / AML readiness | Merchant CDD, CKYCR process, monitoring, FIU-IND registration and reporting framework. |
| Escrow readiness | Domestic PA funds must flow through permitted escrow arrangement with a Scheduled Commercial Bank. |
| Security readiness | Board-approved information-security framework, payment security controls, system audit and cyber-resilience programme. |
| Governance | Board-approved policies, named responsible officers, grievance and dispute framework, internal controls. |
| Regulatory consistency | Application documents, financials, ownership details and technology model should tell the same story. |
Net Worth Requirement for Payment Aggregators
The 2025 Master Direction requires a non-bank entity seeking authorisation to have a minimum net worth of ₹15 crore at the time it tenders the application. It must attain a minimum net worth of ₹25 crore by the end of the third financial year from the grant of authorisation and maintain the applicable minimum on an ongoing basis.
Net worth is not simply the balance shown under ‘share capital’ in the financial statements. The RBI-prescribed computation must be followed and the application should be supported by a statutory auditor’s certificate. Compulsorily convertible preference shares may be included subject to the regulatory conditions, while deferred tax assets included in relevant components have to be deducted when computing net worth. For the exact rule, review paragraph 6 of the RBI PA Master Direction and the linked RBI framework on computation of net worth.
Fit-and-Proper Management and Governance
RBI expects a Payment Aggregator to be professionally managed. Promoters and directors are assessed for fairness, integrity, reputation, honesty and financial soundness. Regulatory, criminal, insolvency and debarment history can materially affect the application.
The governance pack should therefore be prepared before submission, not after a query is received. It generally includes promoter and director declarations, litigation and regulatory disclosures, ownership and group structure, board composition, governance policies, conflict-of-interest controls and evidence that key management can operate a regulated payment business.
Any future takeover, acquisition of control or material management change can also trigger prior RBI approval requirements for non-bank payment system operators.
Documents Required for a Payment Aggregator License
| Document Group | Typical Documents / Evidence |
|---|---|
| Corporate | Certificate of Incorporation, PAN, MoA, AoA, registered office proof, CIN and corporate profile |
| Ownership | Shareholding pattern, group structure, beneficial ownership details, investor information and capital history |
| Management | Director KYC, profiles, declarations, fit-and-proper information, regulatory and litigation disclosures |
| Financial | Audited financial statements, provisional balance sheet where relevant, bank statements, statutory auditor net-worth certificate |
| Business plan | Target merchant segments, payment channels, product architecture, revenue model, three-to-five-year financial projections |
| Payment flow | End-to-end transaction flow, acquiring bank relationships, settlement cycle, refund and chargeback flow |
| Escrow | Proposed escrow bank arrangement, operational flow, permitted credits/debits mapping and reconciliation process |
| Merchant KYC | Merchant acceptance policy, CDD workflow, CKYCR process, CPV approach, beneficial ownership checks and monitoring |
| AML / FIU | AML-CFT policy, risk classification, transaction monitoring, sanctions screening, STR/CTR governance where applicable |
| Cyber security | Information Security Policy, cyber-resilience programme, BCP/DR, incident response, access controls and vendor risk controls |
| Technology | Architecture diagrams, API/security standards, data flow, hosting, encryption, logging, fraud engine and audit trail |
| Customer protection | Grievance policy, escalation matrix, dispute resolution, refund policy, failed-transaction treatment |
| Contracts | Draft merchant agreement, bank/PSP arrangements, vendor agreements, outsourcing clauses and data protection provisions |
| Regulatory | RBI application forms/annexures, declarations, NOC from sector regulator if applicable, board approvals |
Step-by-Step Payment Aggregator License Process
- Business-model classification: determine whether the proposed activity is PA-O, PA-P, PA-CB or a combination, and separate pure gateway/technology functions from regulated fund-handling activity.
- Corporate and object-clause review: confirm the applicant is an Indian company and the MoA permits Payment Aggregator activity.
- Capital review: calculate RBI net worth, address capital gaps, and obtain the statutory auditor certificate in the required format.
- Promoter and management due diligence: prepare fit-and-proper declarations and resolve disclosure inconsistencies before filing.
- Policy and control build-out: prepare merchant onboarding, KYC/AML, information-security, outsourcing, grievance, refund, fraud-risk and business-continuity frameworks.
- Payment-flow and escrow design: document how customer funds enter the system, where they are held, how reconciliation occurs and how merchants are settled.
- Technology and security readiness: prepare architecture, data-flow, access-control, incident-response, audit and cyber-resilience documentation.
- RBI application filing: submit through PRAVAAH with complete annexures, financial evidence and supporting documents.
- RBI scrutiny and queries: respond to information requests, clarifications and deficiencies with consistent documentary evidence.
- Post-authorisation operationalisation: complete escrow, reporting, FIU-IND, audit and merchant-onboarding controls before scaling regulated activity.
Merchant KYC and Due Diligence – Key 2026 Rule
Merchant onboarding is now one of the most important PA compliance areas. The 2025 Master Direction requires a PA to undertake customer due diligence of merchants in accordance with the RBI KYC framework. With the merchant’s consent, the PA should retrieve the merchant’s KYC record from CKYCR while onboarding. Where CKYCR is unavailable, outdated, or cannot be accessed because the PA application is still pending, other permitted KYC mechanisms may be used.
For merchants whose annual turnover does not exceed ₹40 lakh, or whose annual export turnover does not exceed ₹5 lakh, the Master Direction provides an alternative simplified process that includes verified PAN/Form 60, Contact Point Verification and prescribed OVD/business documentation.
The PA must also conduct background and antecedent checks, assign appropriate Merchant Category Code and merchant identifiers, validate the settlement account, monitor merchant transactions against the declared business profile and register with FIU-IND as required.
From 1 January 2026, new merchants should be onboarded under the 2025 due-diligence framework. The transition period for merchants onboarded before the cut-off has also elapsed by the 2026–27 operating period, so existing books should be remediated rather than left under legacy onboarding standards.
Escrow Account and Merchant Settlement
A non-bank PA must maintain merchant funds in a separate escrow account with a Scheduled Commercial Bank in India. For domestic PA activity, the escrow account is used for authorised PA business only. If the entity is authorised for both PA-O and PA-P, the same domestic escrow account can be used for those two activities.
The Master Direction prescribes permitted credits and debits, treatment of refunds and promotional amounts, additional escrow accounts, day-end balance requirements and statutory-auditor certification. Settlement timelines must be transparently agreed with merchants and should be fair and equitable.
Cash-on-delivery collections are not to be operated through the PA escrow account. For PA-CB, inward and outward collection accounts follow separate foreign-exchange rules and cannot be casually mixed with domestic PA funds.
Escrow design should be mapped before the RBI filing because a weak reconciliation or settlement architecture can undermine an otherwise strong application.
Cyber Security, Data and Technology Compliance
Payment Aggregators are payment-system operators with significant technology and data exposure. The applicant should therefore demonstrate security by design rather than rely only on a generic IT policy.
- Board-approved Information Security Policy with ownership, review cycles and measurable controls.
- Fraud detection and prevention systems aligned to merchant and transaction risk.
- Merchant infrastructure checks for PCI-DSS / PCI-SSF applicability.
- Annual system and cyber-security audit by a CERT-In empanelled auditor.
- Business continuity, disaster recovery, resilience testing and incident-response procedures.
- Vendor and outsourcing risk controls with regulatory access and audit rights.
- Payment-system data storage compliance and controlled access to sensitive payment information.
- Cyber incident reporting aligned with RBI and CERT-In requirements.
RBI’s Cyber Resilience and Digital Payment Security Controls for non-bank PSOs are being implemented in phases based on size. Large non-bank PSOs were brought in from 1 April 2025, medium non-bank PSOs from 1 April 2026 and small non-bank PSOs have a later implementation date. A new applicant should therefore build the controls from the start instead of waiting for its size category to become mandatory.
India’s Digital Personal Data Protection framework is also being phased in. The DPDP Rules, 2025 were notified in November 2025, while major substantive provisions have an 18-month commencement path. Payment businesses should use 2026–27 to align privacy notices, consent, processor contracts, retention, breach response and data-principal request processes before the full compliance date applicable to those provisions.
Customer Grievance, Refunds and Failed Transactions
A PA must have a documented dispute-management mechanism and clearly allocate responsibility among the PA, merchant, acquiring bank and other participants. Refunds, failed transactions, chargebacks, return policy, reconciliation and escalation should not be left to informal support practices.
The PA must also publish merchant policies, privacy policy and other terms and conditions, designate an officer for merchant issues, and display a grievance escalation matrix. RBI turnaround-time requirements for failed transactions must be incorporated into operational procedures.
Refunds should ordinarily return to the original payment method unless the payer specifically directs credit to another mode belonging to the same payer. This control reduces misuse and supports transaction traceability.
PA-Cross Border (PA-CB) – Additional Points
Businesses planning cross-border aggregation need a separate regulatory analysis. PA-CB covers qualifying inward and outward current-account transactions through e-commerce for onboarded merchants. The 2025 Master Direction consolidates the earlier cross-border framework into the main PA regime.
- Inward and outward funds must be kept separate; netting or co-mingling is not permitted.
- Foreign exchange may be bought from or sold only to an Authorised Dealer.
- The maximum value per inward or outward PA-CB transaction is ₹25 lakh under the current Master Direction.
- Inward Collection Accounts and Outward Collection Accounts have specific banking and operational requirements.
- FEMA, export/import reporting and EDPMS/IDPMS support obligations must be built into the operating model where applicable.
A domestic-only applicant should not include cross-border flows in its business plan unless it is genuinely ready to meet the additional FEMA, bank-integration and settlement requirements.
Payment Aggregator License Compliance After Approval
RBI authorisation is the beginning of regulated operations, not the end of compliance. A PA should maintain a structured compliance calendar supported by board reporting and evidence retention.
- Maintain the applicable net worth on an ongoing basis and obtain prescribed auditor evidence.
- Maintain and reconcile escrow balances and submit required certificates/reports to RBI.
- Keep merchant due diligence current and perform ongoing transaction monitoring.
- Maintain FIU-IND registration and AML/CFT reporting governance.
- Complete annual system/cyber audit and close findings within documented timelines.
- Keep grievance, refund, failed-transaction and chargeback processes operational.
- Review material outsourcing, vendor, cloud and security arrangements.
- Obtain required RBI approval before qualifying takeover, acquisition of control or management change.
- Keep RBI, bank, merchant and website disclosures consistent with the authorised business model.
Indicative Timeline
There is no guaranteed fixed approval period for a Payment Aggregator authorisation. The actual timeline depends on the applicant’s capital position, business model, completeness of the filing, regulatory history, technology readiness, RBI queries, promoter background and whether changes are required during examination.
| Stage | Indicative Planning Window |
|---|---|
| Pre-application diagnostic | 1–2 weeks |
| Policy, business-plan and application pack | 3–6 weeks, depending on readiness |
| Capital / net-worth restructuring | Depends on funding and corporate actions |
| RBI filing | After complete pack and statutory auditor certification |
| RBI examination | Variable; no guaranteed timeline |
| Query response and remediation | Depends on scope of RBI observations |
| Operationalisation after authorisation | Escrow, FIU, cyber, bank and merchant controls before scale-up |
Payment Aggregator License Fees and Third-Party Costs
Payment Aggregator authorisation is a customised regulatory engagement. Professional fees depend on whether the applicant already has the required capital, policies, technology architecture, merchant KYC framework, banking relationships and audited financials. A precise quote should therefore be issued after the initial eligibility and gap review.
- Professional advisory and application-preparation fee.
- Statutory auditor / certification costs.
- Legal drafting and contract review, where required.
- Cyber-security, VAPT, system audit and CERT-In empanelled auditor costs.
- Banking / escrow implementation costs, if any.
- Corporate restructuring, capital infusion or regulatory NOC work, if applicable.
Government or regulator charges, third-party audit costs and out-of-scope remediation should be shown separately rather than bundled into an unclear package.
Common Reasons an Application Becomes Weak
- Net worth is calculated incorrectly or supported by an inadequate auditor certificate.
- The MoA object clause does not clearly permit the proposed PA activity.
- The business plan describes payment-gateway technology but not the regulated fund flow.
- Promoter, ownership, litigation or group-company disclosures are inconsistent across documents.
- Merchant KYC policy is generic and does not match the RBI 2025 framework.
- Escrow and settlement flows do not reconcile with the proposed product architecture.
- Cyber-security documentation is copied from a generic IT policy and lacks payment-specific controls.
- Revenue projections, merchant acquisition assumptions and technology capacity are not supported.
- Cross-border activity is proposed without adequate FEMA and AD-bank design.
- The applicant treats RBI authorisation as a form-filing exercise rather than a regulatory capability assessment.
Why Choose Vakilkaro?
- Regulatory-first approach instead of a generic licensing checklist.
- Integrated legal, company-law, finance and compliance review.
- Client-friendly explanation of capital, merchant KYC, escrow and cyber obligations.
- Document consistency checks before filing to reduce avoidable regulatory queries.
- Support for related company, GST, trademark Registration, agreement and compliance requirements.
- Clear separation of professional fees, regulator requirements and third-party costs.
- Ongoing support after authorisation for compliance implementation and policy updates.
