Table of Contents
If you collect payments online in India, whether it’s fees, subscriptions, invoices, or e-commerce checkout, you’ll likely evaluate payment aggregator vs payment gateway options early.
The confusion is understandable because both models sit inside the same customer journey: “Pay Now” → authorisation → confirmation → settlement. The difference shows up in who handles funds, how settlements happen, and what the Reserve Bank expects from each player.
This blog breaks down payment aggregator vs payment gateway in plain terms, using the latest regulatory framework from the Reserve Bank of India.
Payment Aggregator vs Payment Gateway definitions that matter
A Payment Gateway (PG) is primarily a technology layer. RBI defines a payment gateway as an entity that provides the infrastructure to route and facilitate the processing of a payment transaction without being involved in handling funds.
A Payment Aggregator (PA), on the other hand, sits closer to the money movement. RBI defines a payment aggregator as an entity that aggregates payments made by customers to merchants through one or more payment channels (through the merchant’s physical or virtual interface) and then subsequently settles the collected funds to those merchants. In the latest RBI master direction, PAs are also categorised into online, physical, and cross-border types, depending on where and how the acceptance happens.
Important: a PA and a PG are not always mutually exclusive in the real world. RBI explicitly notes that a PA may avail the services of a PG (subject to applicable outsourcing and IT-related directions), which is why many solutions feel “bundled” from a merchant’s perspective.
Comparison table: Payment Aggregator vs Payment Gateway
Attribute | Payment Aggregator (PA) | Payment Gateway (PG) |
Definition | Aggregates customer payments for merchants and settles collected funds to merchants. | Routes/facilitates payment processing without handling funds. |
Who holds funds | Non-bank PAs must keep funds collected on behalf of merchants in a separate escrow account with a Scheduled Commercial Bank (SCB). | Does not hold funds (technology routing layer). |
Settlement flow | Customer → PA → escrow/collection account → merchant payout (per rules + merchant agreement). | Customer → PG routes transaction → banks/payment systems → funds flow to merchant via acquiring setup (PG itself doesn’t touch funds). |
Compliance | Non-bank PAs need RBI authorisation and must meet net-worth, escrow, KYC, reporting and security requirements. | RBI’s framework describes PG as a routing entity; the heavy licensing and escrow requirements are targeted at PAs. |
Typical fees | Generally transaction-based (percentage + taxes), sometimes blended by payment mode; settlement cycle and risk controls can influence effective cost. (Fee structures vary by business type and volumes.) | Typically transaction-based (percentage + taxes), sometimes plus setup/tech charges depending on integration model. (Negotiation depends on volumes and risk.) |
Best for | Businesses that want simpler onboarding, consolidated reporting, and multi-mode acceptance with PA-managed compliance. | Businesses that want a routing layer and have (or will set up) the acquiring/merchant banking structure and operational capability. |
How each model works with workflows, merchants can map
To choose correctly, it helps to separate payment authorisation from settlement. Authorisation is the “approved/declined” response in seconds. Settlement is the actual movement of money into the merchant’s bank account, often on a timeline and under rules. Here are the key roles most Indian businesses encounter in either model:
- Customer (payer): uses UPI, card, netbanking, wallet, etc.
- Merchant: website/app/ERP/invoicing workflow that collects payments.
- Payment Gateway (routing): encrypts and routes data to acquiring rails (without holding funds).
- Payment Aggregator (collection + settlement): collects funds and later settles them to the merchant; manages escrow/collection accounts.
- Acquiring bank: a bank that provides merchant acquiring and settlement access; in PA models, RBI clarifies how acquiring banks can rely on PA due diligence while still maintaining policy oversight.
Compliance in India under RBI payment aggregator guidelines
India’s regulatory expectation is clear: entities that handle and settle funds for merchants attract stricter oversight than entities that only provide routing technology. Two key RBI instruments matter for most businesses evaluating this space.
The earlier framework many merchants still reference is RBI’s “Guidelines on Regulation of Payment Aggregators and Payment Gateways” (circular dated March 17, 2020, under RBI/DPSS/2019-20/174 / DPSS.CO.PD.No.1810/02.14.008/2019-20). It clarified that PAs (especially non-bank PAs) require RBI authorisation, while PGs were provided baseline technology recommendations.
The current consolidated framework is the Master Direction on Regulation of Payment Aggregator (PA) dated September 15, 2025. RBI notes that it issued the 2020 PA/PG guidelines and subsequent directions, then moved to a comprehensive master direction after additional inputs and drafts. It also specifies that earlier circulars/guidelines are repealed as described in the master direction.
Net-worth requirements: why they exist
Under the 2025 master direction, an entity seeking authorisation to commence or carry on PA business must have a minimum net worth of ₹15 crore at application, and attain ₹25 crore by the end of the third financial year from the grant of authorisation, maintaining it on an ongoing basis.
The 2020 guidelines also set similar thresholds and included timelines for existing PAs at that time, emphasising that non-compliant entities would need to wind up their payment aggregation business.
Escrow and fund segregation: where the money must sit
RBI’s 2025 master direction states that a non-bank PA must maintain funds collected on behalf of its merchants in a separate escrow account with a Scheduled Commercial Bank in India. For cross-border PAs, RBI also defines inward and outward collection accounts (InCA/OCA), with operational restrictions and segregation expectations.
The directions also detail permitted credits/debits and operational controls for escrow accounts, and require these accounts to be used only for authorised PA business.
Settlement timelines: what merchants should understand
RBI’s 2020 guidelines laid out explicit settlement timelines tied to delivery/refund logic, such as settling to the merchant not later than Ts + 1 or Td + 1, with a specific clause allowing settlement not later than Tr + 1 when the agreement provides that the PA keeps funds until the refund period expires.
In the 2025 master direction, the escrow table emphasises that credit to the merchant’s account must be as per the agreement between the PA and the merchant, and also adds an important merchant-protection principle: the agreement should be fair and equitable and must transparently mention settlement timelines.
The directions also detail permitted credits/debits and operational controls for escrow accounts, and require these accounts to be used only for authorised PA business.
Merchant due diligence and onboarding rules
RBI expects PAs to conduct merchant due diligence aligned to KYC expectations, including retrieving merchant KYC records from CKYCR (with consent) where applicable. RBI also provides an alternative process for smaller merchants under certain turnover thresholds, and requires background/antecedent checks and ongoing monitoring to ensure transactions match the merchant’s business profile.
RBI further clarifies the responsibilities of the acquiring bank in a PA-led setup: the acquiring bank must have a policy for merchants acquired through an authorised non-bank PA, and while it need not do KYC itself, it should be able to obtain required details and ensure compliance with its own merchant acquiring policy.
Security expectations: data, merchant infrastructure, and card credentials
Security is not a “nice-to-have” in this model because PAs handle large volumes and sensitive data. RBI’s framework includes baseline security and technology expectations, and (in the 2020 guideline annexures) explicitly states that customer card credentials should not be stored within databases/servers accessed by the merchant.
The 2025 master direction also links risk management and security controls to merchant infrastructure compliance with standards like PCI-DSS/PCI-SSF (as applicable).
Onboarding and merchant experience in both models
From a merchant’s point of view, onboarding is where the difference is felt immediately.
- With a Payment Aggregator, onboarding is typically designed to be faster and more standardised because the PA must complete merchant due diligence and implement ongoing monitoring. RBI’s master direction confirms that PAs undertake customer due diligence of merchants and must ensure validations like crediting funds to the merchant’s bank account only.
- With a Payment Gateway (routing-only), the technology integration can be straightforward, but the merchant may still need to complete acquiring-side approvals and operational readiness (reconciliation, disputes, refund processes). RBI’s definition frames the PG as a routing infrastructure without handling funds, which means the merchant’s operational setup and acquiring arrangement become central to how smoothly settlements and disputes run.
Where SabPaisa fits in for India-first collections
For Indian businesses that want a compliant, multi-mode collection setup without overcomplicating the process, SabPaisa positions its infrastructure around regulated operations and security standards.
SabPaisa is a hybrid payments platform that enables online collections and offline collections (cash/cheque via authorised partner bank branches/counters linked to a digital transaction) within one reporting and reconciliation framework.
SabPaisa is an RBI-authorised payment aggregator with PCI-DSS and ISO-certified security controls.
SabPaisa is a unified online and offline collection service and is an RBI-authorised, PCI-DSS & ISO-certified payment gateway service provider for a wide range of organisations.
It also offers merchant-friendly collection formats like Payment Links (including “no website, coding, or complex setup” messaging) and Hosted Payment Pages that emphasise secure, compliant checkout and encrypted processing.
Conclusion
Choosing between Payment Aggregator vs Payment Gateway is less about labels and more about understanding responsibilities. If your provider handles merchant funds and settlement, it falls into PA expectations like authorisation, net worth, escrow operations, KYC/due diligence, reporting, and security controls.
If it is a routing-only layer, it aligns to the PG definition and your acquiring/operational setup becomes the backbone of settlements and disputes. Start by mapping your payment journeys (checkout vs invoices/links), your cash-flow sensitivity, and the compliance comfort you need across your teams, and then select the model accordingly.
FAQs
A payment gateway is a technology service that routes a payment transaction for processing. RBI describes it as an entity that provides infrastructure to route and facilitate payment processing without handling funds.
A payment aggregator is an entity that aggregates customer payments for merchants and later settles the collected funds to those merchants. RBI also categorises PAs into online, physical, and cross-border, depending on the transaction context.
RBI’s framework places the core authorisation, net-worth, escrow, due diligence, and reporting requirements on entities operating as payment aggregators, especially non-bank PAs. The payment gateway is defined as a routing entity without handling funds, which changes the compliance scope significantly.
RBI requires non-bank PAs to hold merchant collections in a separate escrow account with an SCB and prescribes operational requirements for those accounts. The 2020 PA/PG guidelines also specified delivery/refund-linked outer limits like Ts+1/Td+1/Tr+1, while the 2025 master direction emphasises transparent, fair settlement timelines in the merchant agreement (along with escrow controls).
Yes. RBI states that a PA may avail the services of a PG, subject to relevant outsourcing and IT-related directions. This is why many business offerings appear “PA + PG together” from the merchant’s point of view.
