How to Build a Payment Aggregator in India (PA-O, PA-P and PA-CB): 2026 Guide
AI Summary: Building a Payment Aggregator in India requires more than payment gateway integration. Businesses must understand the PA-O, PA-P, and PA-CB categories, meet applicable RBI authorisation requirements, establish secure payment infrastructure, and implement KYC, AML, risk management, and settlement processes. This guide explains the key regulatory, technical, and business considerations for launching a compliant Payment Aggregator in 2026. |
In September 2025 the Reserve Bank of India brought every kind of payment aggregator under one rulebook: the RBI (Regulation of Payment Aggregators) Directions, 2025. Online, in-store and cross-border aggregators now follow one set of rules on capital, escrow, merchant checks and security.
For founders and product teams this changes the build question. It is no longer just "how do we make a payment gateway?" It is "which role are we allowed to play, and what must the software prove to the regulator every day?" This guide answers both. It covers the categories, the choice between your own authorisation and a partner route, the modules the Directions force you to build, the integrations involved, and what drives cost and timeline.
If you are mapping licences across markets first, start with our Fintech Licensing Requirements 2026 guide, then come back here for the India build.
What counts as a payment aggregator under RBI rules
The Directions define a payment aggregator (PA) as an entity that collects payments from customers for merchants, through the merchant's interface, and then settles those funds to the merchants. The key point is that the money passes through you. If your product only sends API calls and never touches funds, you are a technology provider, not a PA.
The Directions split PAs into three categories:
Category | What it covers | Typical products |
PA-O (Online) | Payments where the acceptance device and the payment instrument are not physically close | Checkout pages, payment links, subscription billing, marketplace collections |
PA-P (Physical) | Payments where the acceptance device and the instrument are physically close | POS terminals, SoftPOS / tap-to-phone, in-store QR |
PA-CB (Cross-border) | Cross-border current-account payments for onboarded e-commerce merchants, inward or outward | Export collections, overseas checkout for Indian buyers |
Two notes from the Directions matter for product scope. Banks do not need separate PA authorisation. And for PA-P, an entity running only physical aggregation had to apply by 31 December 2025, or tell its bankers and wind the business down by 28 February 2026. If you are entering in-store acceptance now, you are either authorised, applying as a new entity, or working under someone who is.
Own authorisation or partner route?
This is the most expensive decision in the project, so make it first.
Own Certificate of Authorisation (CoA). Under the Directions a non-bank PA must be a company incorporated in India under the Companies Act, 2013, with the PA activity in its Memorandum of Association. It must have a net worth of at least ₹15 crore when it applies and reach ₹25 crore by the end of the third financial year after authorisation, and it must keep that level on an ongoing basis. Promoters and directors must meet RBI's fit-and-proper criteria. You also carry escrow, audit and reporting duties for as long as you operate.
Sub-merchant or platform on a licensed PA. Many marketplaces and vertical SaaS products onboard their sellers as sub-merchants of an authorised PA, using that PA's split-settlement or route features. The PA holds the funds and carries the regulatory duties. You build the experience and the merchant operations around it.
Technology service provider to a PA or bank. You build switching, risk, reconciliation or terminal software and license it to an authorised PA or acquiring bank. You never hold funds, but your client will flow its compliance needs down into your contract.
Route | Who holds funds | Capital you need | Time to launch | Best for |
Own PA authorisation | You (via escrow with a bank) | ₹15 crore at application, ₹25 crore by year 3 | Long: application review plus build | Payments companies whose core business is acquiring |
Sub-merchant / platform on a licensed PA | The licensed PA | Ordinary company capital | Weeks to a few months | Marketplaces, SaaS, D2C, lending and wealth apps that need collections |
Tech provider to a PA or bank | Your client | Ordinary company capital | Depends on client contract | Teams selling switch, risk, recon or POS software |
A sensible path for most startups: launch on a licensed PA, prove volume and unit economics, and keep the architecture ready to become your own PA later. Design your ledger and merchant data model so the switch does not need a rewrite.
What the 2025 Directions mean for your software
Every section of the Directions turns into code, controls or reports. These are the areas to plan for.
Merchant onboarding and due diligence
The Directions require PAs to do customer due diligence on merchants and to check their background before onboarding. Your onboarding module needs:
Business identity checks (PAN, GSTIN where applicable, incorporation documents) through KYC/KYB API providers
Beneficial owner and director checks, with sanctions and adverse-media screening
Website and business-model review, with a list of prohibited categories
Risk scoring that sets limits, holds and settlement cycles per merchant
Periodic re-KYC and ongoing monitoring, with a full audit trail
If you also run lending or wealth products, reuse the same KYC stack. Our guide to unified KYC (CKYC) explains the India building blocks.
Escrow and settlement
A non-bank PA must keep collected funds in an escrow account with a scheduled commercial bank and settle merchants within the timelines RBI sets. In software terms that means:
A double-entry ledger that tracks every rupee from customer payment to merchant settlement
Daily reconciliation between your ledger, the escrow bank statement and network or UPI settlement files
Settlement scheduling per merchant (T+1 and so on), with holds, reserves and chargeback adjustments
Reports that show escrow balances against amounts owed to merchants
Reconciliation is where most homegrown PAs struggle. Build it as a product of its own, not as a cron job.
Refunds
The Directions require refunds to go back to the original payment method unless the customer chooses otherwise. Your refund engine must store the original instrument reference, route the refund back through the same rail, and record any customer instruction to use a different method.
Security, data storage and audits
PAs must meet strong security standards, including PCI-DSS for card data, and follow RBI rules on card-data storage and data localisation. Plan for:
Card tokenisation through networks or the issuing side, so you do not store full card numbers
Encryption of sensitive data at rest and in transit, with key management (HSM or cloud KMS)
Payment data stored in India
Logging and monitoring that will stand up to the cyber audits the Directions call for
A board-approved information security policy that matches what you actually build
PA-CB extras
Cross-border aggregation adds foreign-exchange rules. The Directions require inward and outward flows to be handled separately, set a per-transaction cap of ₹25 lakh for outward payments, and route funds through AD Category-I banks. Your PA-CB build needs purpose-code tagging, FX rate capture, transaction-limit checks, separate collection accounts and reporting that matches what the AD bank needs.
Reference architecture
A PA platform looks like a set of services around a ledger. This is the module map we use when scoping:
Module | What it does | Notes |
Merchant onboarding & KYB | Applications, document checks, risk scoring, agreements | Drives limits and settlement cycles |
Checkout & payment APIs | Hosted checkout, SDKs, payment links, subscriptions | Idempotent APIs, webhooks, retries |
Payment router / switch | Routes to banks, card networks and UPI, with failover | Success-rate based routing |
Tokenisation & vault | Card tokens, mandates | Keeps full card data out of your systems |
Ledger | Double-entry record of every movement | The single source of truth |
Reconciliation | Matches ledger, bank, network and UPI files | Daily breaks report |
Settlement & payouts | Merchant settlements, splits, reserves | Escrow-aware |
Risk & fraud | Velocity rules, device signals, merchant monitoring | Feeds holds and chargebacks |
Disputes & refunds | Chargebacks, refunds to source | Linked to the original transaction |
Compliance reporting | Regulatory returns, audit logs, escrow reports | Generated from the ledger |
Merchant dashboard | Transactions, settlements, reports, API keys | Self-serve reduces support load |
Most teams build this as microservices on a cloud region in India, with PostgreSQL for the ledger, an event bus (Kafka or similar) between services, and Redis for idempotency and rate limiting.
Key integrations and APIs
Acquiring and sponsor banks: for card acquiring, escrow and settlement accounts
Card networks: through your acquiring bank, plus network tokenisation
UPI: through a partner bank and NPCI's rules for merchant acquiring
Net banking and wallets: bank-by-bank or through an aggregator partner
KYC/KYB providers: PAN, GSTIN, MCA and bank-account checks. See our guide to the Karza API for one example
AD-I bank APIs for PA-CB flows
Fraud and device intelligence services
If you are launching on a licensed PA first, the integration is much smaller: the PA's APIs for orders, payments, split settlements, refunds and webhooks. Our Razorpay vs PayU comparison helps with that choice.
Cost and timeline drivers
We do not quote fixed prices without a scope. These are the factors that move the number most:
Route: a platform on a licensed PA can launch in weeks. Your own PA means a full ledger, recon, risk and reporting stack plus the authorisation process, which RBI controls.
Number of payment methods: each bank, network or wallet connection adds integration, certification and testing work.
Categories: PA-P adds terminal management and device certification. PA-CB adds FX, purpose codes and AD-bank reporting.
Reconciliation complexity: split payments, marketplaces and partial refunds multiply the matching rules.
Audit readiness: PCI-DSS, security audits and documentation take real calendar time.
For a rough view of transaction costs on the partner route, try our payment processing fee calculator.
Build plan in phases
Decide the route. Own CoA, sub-merchant platform or tech provider. Get legal advice on whether your fund flow makes you a PA.
Design the ledger and data model so a later move from partner to own authorisation does not force a rewrite.
Build onboarding, checkout and webhooks on a licensed PA or your own switch.
Add reconciliation, settlement and reporting.
Harden security for PCI-DSS and audit readiness.
Add PA-P or PA-CB only when the core flows are stable.
Build your payment aggregator with Fintegration
Fintegration builds payment, lending and wealth platforms for fintechs in India and the US. We can help you choose between the partner and own-authorisation routes, design the ledger and reconciliation layer, and integrate the banks, UPI and KYC providers you need. Talk to our team to scope your build.
FAQ
1. What is a Payment Aggregator in India?
A Payment Aggregator (PA) helps businesses accept online payments through multiple methods without setting up direct banking integrations for each payment option.
2. What is the difference between PA-O, PA-P, and PA-CB?
PA-O covers online payment aggregation, PA-P focuses on physical or offline payment acceptance, and PA-CB handles cross-border payment aggregation.
3. Do I need RBI approval to start a Payment Aggregator business in India?
Yes. Payment Aggregators generally need RBI authorisation under the applicable guidelines before commencing regulated operations.
4. What are the key requirements to build a Payment Aggregator in India?
You need the right business structure, regulatory approvals, secure payment infrastructure, KYC and AML processes, risk monitoring, and settlement systems.
5. How much does it cost to build a Payment Aggregator platform in India?
The cost depends on platform complexity, payment integrations, security requirements, compliance setup, and infrastructure. Regulatory capital requirements should also be considered separately.
