Machine Learning pathway increased my salary by 40%
Advanced Fintech & PaymentsPayment Foundations & Core ArchitectureTopic 2
Payment Aggregators vs Payment Gateways vs PayFacs: Architecture and Business Models
Understanding the architectural and business model differences between payment aggregators, gateways, and payment facilitators
Quick Answer
Payment gateways, aggregators, and payment facilitators (PayFacs) are often confused but have distinct architectures and business models. A payment gateway is the technology that transmits payment data. A payment aggregator (PA) is a licensed entity that onboards merchants and processes payments under its own license. A PayFac is a specialized aggregator that enables sub-merchants to accept payments under the PayFacs master merchant account. In India, RBI regulates PAs and PayFacs separately.
Learning Objectives
1Understand architectural and business model differences between gateways, aggregators, and PayFacs
2Design appropriate architecture for each payment entity type
3Navigate regulatory requirements for PAs and PayFacs in India and globally
4Build merchant onboarding systems for each model
5Design settlement and reconciliation for multi-party payment processing
Executive Summary
The payments industry uses several models for enabling merchants to accept digital payments. Understanding the differences between payment gateways, aggregators, and PayFacs is essential for architects, product managers, and compliance professionals.
A payment gateway provides the technology to transmit payment data. A payment aggregator (PA) is a licensed entity that onboards merchants, processes payments, and settles funds. A PayFac enables sub-merchants under a master merchant account.
Each model has distinct regulatory requirements, settlement flows, risk management approaches, and business economics.
What Is Payment Aggregators vs Payment Gateways vs PayFacs: Architecture and Business Models?
A payment gateway is the technology infrastructure that transmits payment data between a merchant and the payment processor. A payment aggregator (PA) is a licensed entity that onboards sub-merchants and processes payments on their behalf. A payment facilitator (PayFac) is a specialized aggregator that enables sub-merchants to accept payments under the PayFacs master merchant account.
Why This Topic Matters
Choosing the right model determines the regulatory burden, risk exposure, and business economics of a payment business.
Each model has different compliance requirements, settlement flows, and merchant onboarding processes.
In India, RBI has specific guidelines for PAs and is developing frameworks for PayFacs.
Why It Matters in 2026+
In 2026, the lines between gateways, aggregators, and PayFacs are blurring as platforms add capabilities across models.
RBI is evolving its regulatory framework for payment entities, with new requirements for data localization, escrow management, and merchant KYC.
The rise of embedded finance and BaaS is creating new models where platforms offer payment capabilities to their merchants.
Architecture Overview
Architecture differences between gateway, aggregator, and PayFac models:
Reference Architecture
Merchant
↓
Gateway/PA/PayFac
↓
Acquirer
↓
Card Network
↓
Issuer
↓
Settlement
In the gateway model, the merchant has a direct acquiring relationship. In the PA model, the aggregator holds the acquiring relationship. In the PayFac model, sub-merchants are onboarded under the PayFacs master merchant account.
Core Components
| Component | Gateway | PA | PayFac |
|---|---|---|---|
| Merchant Onboarding | Direct MID | PA onboards | Sub-merchant under master MID |
| Acquiring | Merchant-acquirer | PA-acquirer | PayFac-acquirer (master) |
| Settlement | Direct to merchant | PA to merchant (escrow) | PayFac to sub-merchant |
| KYC | Acquirer does | PA does | PayFac does for sub-merchants |
| Risk | Merchant bears | PA bears merchant risk | PayFac bears sub-merchant risk |
| Regulation | PCI DSS, network | RBI PA license, PCI | RBI PayFac, PCI |
Detailed Technical Architecture
Technical architecture for each model:
Gateway Architecture
Technology-only: API gateway, payment processing, tokenization. No merchant onboarding or settlement.
PA Architecture
Gateway + merchant onboarding + escrow management + settlement + KYC + risk management.
PayFac Architecture
PA + sub-merchant onboarding under master MID + sub-merchant settlement + sub-merchant risk monitoring.
Regulatory Considerations
Regulatory requirements by model:
| Requirement | Gateway | PA | PayFac |
|---|---|---|---|
| RBI License | Not required | PA license | PayFac framework |
| Escrow Account | Not required | Mandatory | Mandatory |
| Merchant KYC | Acquirer does | PA does | PayFac does |
| T+1 Settlement | N/A | Mandatory | Mandatory |
| Data Localization | PCI scope | Mandatory | Mandatory |
| Net Worth | N/A | Rs 15 crore min | Higher threshold |
Vendor Landscape
Stripe (PayFac)
Acts as PayFac globally, enabling sub-merchants under master account.
PayFacGatewayAggregation
Razorpay (PA)
RBI-licensed payment aggregator in India.
PA licenseGatewayMulti-rail
Adyen (Gateway+Acquirer)
Direct acquiring + gateway for enterprises.
GatewayDirect acquirer
Real Enterprise Case Studies
Real-world implementations:
StripeUSA · Fintech
Context: Global PayFac enabling millions of sub-merchants.
Problem: Simplify merchant onboarding while managing sub-merchant risk.
Architecture: PayFac model with master merchant account. Automated sub-merchant onboarding with risk scoring.
Technology: Ruby, Go, custom risk engine
Outcomes: Millions of sub-merchants. Instant activation for low-risk.
Lessons: PayFac enables instant onboarding. Risk management is critical.
RazorpayIndia · Fintech
Context: RBI-licensed payment aggregator serving 10M+ merchants.
Problem: Navigate RBI PA guidelines while providing seamless merchant experience.
Architecture: PA model with escrow account, T+1 settlement, merchant KYC.
Technology: Go, PostgreSQL, Kafka, AWS
Outcomes: 10M+ merchants. RBI PA license. T+1 settlement.
Lessons: RBI PA compliance is essential. Escrow management is critical.
Common Architecture Mistakes
Storing Raw Card Data
Storing PAN or CVV in databases creates massive PCI DSS scope and security risk. Always use tokenization.
No Idempotency on Payment APIs
Missing idempotency keys on payment endpoints causes duplicate charges on retries. Every payment API must support idempotency.
Synchronous Processing of Async Operations
Treating inherently asynchronous payment operations as synchronous causes timeouts and poor UX. Use webhooks and async patterns.
No Webhook Retry Logic
Failing to retry failed webhook deliveries causes merchants to miss critical payment status updates. Implement exponential backoff retry.
No Reconciliation Automation
Manual reconciliation at scale is error-prone and slow. Automate reconciliation from day one.
Single-Rail Dependency
Depending on a single payment rail creates a single point of failure. Implement multi-rail architecture with failover.
No Fraud Monitoring
Launching without fraud monitoring leads to chargebacks and losses. Implement real-time fraud detection from day one.
Payment Database as Financial Ledger
Using the transaction database as the financial ledger leads to accuracy and audit issues. Maintain a separate double-entry ledger.
KPIs
| KPI | Description | Target |
|---|---|---|
| Authorization Rate | Percentage of payment attempts that receive authorization | > 95% |
| Payment Success Rate | Percentage of initiated payments that complete successfully | > 97% |
| API Latency (p99) | 99th percentile API response time | < 500ms |
| TPS Capacity | Transactions per second the system can handle | Based on peak demand |
| Fraud Rate | Fraudulent transactions as percentage of total | < 0.1% |
| Chargeback Rate | Chargebacks as percentage of transactions | < 0.75% |
| Uptime | System availability | 99.99% |
| Reconciliation Accuracy | Percentage of transactions successfully reconciled | > 99.5% |
Practical Project
Design a PayFac Platform
Objective: Design architecture for a PayFac that onboards sub-merchants under a master merchant account.
Scenario: Build a PayFac platform for a marketplace that needs to enable sellers to accept payments without each needing direct acquiring.
Tasks:
- Design sub-merchant onboarding with KYC
- Design master merchant account architecture
- Design sub-merchant settlement and reconciliation
- Design sub-merchant risk monitoring
- Design regulatory compliance framework
Deliverables: Architecture document, onboarding flow, settlement design, risk model, compliance plan.
Validation: Onboard a test sub-merchant. Process a payment. Verify settlement to sub-merchant. Verify risk monitoring.
Interview Questions
Difference between PA and PayFac?
A PA onboards merchants with their own MIDs. A PayFac onboards sub-merchants under a master MID. PayFacs simplify onboarding but bear more risk.
Why do PAs need an escrow account?
RBI requires PAs to maintain escrow to protect merchant funds. Customer payments go to escrow, PA settles to merchants from escrow.
Frequently Asked Questions (52)
Glossary
PSP
Payment Service Provider: entity that enables merchants to accept payments through multiple payment methods via a single integration.
PayFac
Payment Facilitator: entity that enables sub-merchants to accept payments under the PayFac master merchant account.
Acquirer
Bank or financial institution that processes card transactions on behalf of merchants.
Issuer
Bank or financial institution that issues payment cards to consumers.
Interchange
Fee paid between the acquiring bank and the issuing bank for card transactions, set by card networks.
MID
Merchant ID: unique identifier assigned to a merchant by the acquirer.
PAN
Primary Account Number: the 14-19 digit number on a payment card, considered sensitive cardholder data under PCI DSS.
Tokenization
Process of replacing sensitive card data with a non-sensitive token.
Authorization
Process of verifying that a payment account has sufficient funds and is valid for a transaction.
Capture
Process of finalizing a previously authorized transaction, triggering the transfer of funds.
Clearing
Process of exchanging transaction details between acquiring and issuing banks.
Settlement
Actual transfer of funds between banks to complete a payment transaction.
Chargeback
Transaction dispute initiated by a cardholder through their issuing bank.
MCC
Merchant Category Code: 4-digit code classifying the type of goods or services a merchant sells.
3DS
3-D Secure: authentication protocol for card-not-present transactions.
PCI DSS
Payment Card Industry Data Security Standard: security standard for organizations handling cardholder data.
HSM
Hardware Security Module: physical computing device that safeguards and manages digital keys.
Idempotency
Property of an API where making the same request multiple times produces the same result as making it once.
Webhook
HTTP callback triggered by an event, used in payments for asynchronous notifications.
UPI
Unified Payments Interface: India real-time payment system developed by NPCI.
NPCI
National Payments Corporation of India: umbrella organization for retail payment systems in India.
RBI
Reserve Bank of India: India central bank and regulatory authority for payment systems.
ISO 20022
International standard for electronic data interchange between financial institutions.
ACH
Automated Clearing House: US electronic payment network for batch-processed bank-to-bank transfers.
FedNow
US Federal Reserve instant payment service launched in 2023.
SEPA
Single Euro Payments Area: EU payment integration initiative.
RTP
Real-Time Payments: payment infrastructure enabling instant, irrevocable payments 24/7.
Ledger
Financial record-keeping system using double-entry accounting.
Reconciliation
Process of matching transaction records across different systems to ensure consistency.
Escrow
Financial arrangement where a third party holds funds until conditions are met.
BNPL
Buy Now Pay Later: short-term financing allowing consumers to pay in installments.
BaaS
Banking-as-a-Service: model where licensed banks provide banking infrastructure via APIs.
Open Banking
Practice of providing secure API access to bank account data and payment initiation.
Embedded Finance
Integration of financial services into non-financial platforms via APIs.
Stablecoin
Cryptocurrency designed to maintain stable value by pegging to a reference asset.
Sub-merchant
Merchant onboarded under a PayFacs master merchant account.
Master MID
Merchant ID under which PayFac sub-merchants process payments.
Implementation Checklist
- Architecture designed and reviewed
- API contracts defined with idempotency
- Authentication and authorization implemented
- PCI DSS scope assessed and minimized via tokenization
- Error handling and retry logic designed
- Webhook delivery and retry implemented
- Security review completed (encryption, HSM, key management)
- Regulatory requirements identified (RBI, PCI DSS, AML)
- Data model defined (transactions, ledger, reconciliation)
- Observability implemented (metrics, logs, traces, alerts)
- Testing completed (unit, integration, load, chaos)
- Disaster recovery designed and tested
- Reconciliation process validated
- Fraud detection deployed and tuned
- Production readiness assessed and approved
Career & Enterprise Skills
Payment Architect
Designs end-to-end payment architecture including gateways, orchestration, rails, security, and compliance.
Fintech Architect
Designs comprehensive fintech platform architecture including payments, banking, ledgers, risk, and compliance.
API Architect
Designs API-first payment platforms including REST APIs, webhooks, SDKs, developer portals, and API governance.
Payment Engineer
Implements and operates payment infrastructure including gateway, routing, processing, reconciliation, and settlement.
Platform Engineer
Builds internal developer platforms for payment integration, providing self-service APIs, SDKs, and golden paths.
SRE Engineer
Applies software engineering to payment operations, managing SLI/SLO/error budgets and incident response.
Fraud Analyst
Monitors transaction patterns, investigates suspicious activity, tunes fraud rules, and manages chargeback disputes.
Fintech Product Manager
Defines payment product strategy, manages roadmap, balances user experience with compliance, and drives payment metrics.
Compliance Specialist
Ensures payment systems meet PCI DSS, RBI, AML, and other regulatory requirements.
Treasury Technology Specialist
Implements and operates treasury management systems including liquidity management, settlement, FX, and bank connectivity.
Future Outlook
2027: Payment Aggregators vs Gateways vs PayFacs will see increased AI integration with AI agents handling routine payment decisions, intelligent routing optimization, and predictive fraud prevention becoming standard capabilities.
2028: Autonomous payment systems will mature with self-healing infrastructure, AI-driven reconciliation, and cross-border real-time payments reducing settlement time from days to seconds.
2029: Programmable money and tokenized deposits will enable new payment models with conditional settlement, smart contract-based escrow, and machine-to-machine payments becoming practical.
2030: The convergence of AI, blockchain, and real-time payments will be complete. Payment Aggregators vs Gateways vs PayFacs will be managed through AI agents with humans governing policy, security, and business alignment. Payments will be invisible, instant, and intelligent.
Key Takeaways
- Gateway, PA, and PayFac are distinct models with different regulatory, risk, and business implications.
- RBI PA license is mandatory for payment aggregators in India with escrow, T+1, and KYC requirements.
- PayFac model enables instant merchant onboarding but requires robust sub-merchant risk management.
- The choice of model determines regulatory burden, risk exposure, and business economics.