Machine Learning pathway increased my salary by 40%
Advanced Fintech & PaymentsEmbedded Finance & Payment Platform ArchitectureTopic 15
Payment Service Provider (PSP) Architecture and Merchant Onboarding
Complete architecture for building a Payment Service Provider with merchant onboarding, processing, and settlement
Quick Answer
A Payment Service Provider (PSP) enables merchants to accept payments through multiple methods via a single integration. PSP architecture includes merchant onboarding (KYC, underwriting), payment processing (multi-rail), settlement (fund transfer to merchants), reconciliation, and merchant dashboard. Key components include API gateway, payment service, rail connectors, ledger, settlement service, and merchant management. PSPs like Stripe, Razorpay, and Adyen process billions in annual payment volume.
Learning Objectives
1Design PSP architecture with merchant onboarding and payment processing
2Implement merchant KYC, underwriting, and risk management
3Build settlement and payout systems for merchants
4Design merchant dashboard and self-service capabilities
5Handle multi-rail processing and reconciliation
Executive Summary
A Payment Service Provider (PSP) is a platform that enables merchants to accept digital payments through a single integration, supporting multiple payment methods (cards, UPI, wallets, bank transfers). PSPs handle merchant onboarding, payment processing, settlement, and reconciliation.
Key architectural components include: merchant onboarding with KYC/underwriting, payment processing with multi-rail support, settlement with payout scheduling, reconciliation across rails, and merchant dashboard for self-service.
This topic covers PSP architecture, merchant lifecycle management, and operational considerations for building and running a PSP.
What Is Payment Service Provider (PSP) Architecture and Merchant Onboarding?
A Payment Service Provider (PSP) is a platform that enables merchants to accept digital payments through a single integration, supporting multiple payment methods. The PSP handles merchant onboarding (KYC, underwriting), payment processing (authorization, capture, settlement), reconciliation, and merchant support. PSPs aggregate merchants under their own merchant account or facilitate direct merchant accounts.
Why This Topic Matters
PSPs are the primary way merchants accept digital payments. They simplify payment acceptance by providing a single integration for multiple payment methods, handling compliance, and managing settlement.
For merchants, a good PSP reduces integration complexity, improves payment success rates, and provides analytics and reporting. For the PSP, the business model is based on transaction fees and value-added services.
Why It Matters in 2026+
In 2026, PSPs are evolving to offer more than payment processing: embedded finance, lending, cards, and banking. The lines between PSPs, BaaS, and embedded finance platforms are blurring.
AI-driven PSPs are emerging with intelligent routing, automated underwriting, and AI-powered merchant support.
Architecture Overview
PSP architecture:
Reference Architecture
Merchant Onboarding
↓
Payment Processing
↓
Settlement
↓
Reconciliation
↓
Merchant Dashboard
Merchants onboard with KYC and underwriting. Payments are processed through multiple rails. Settlement transfers funds to merchant accounts. Reconciliation matches transactions across systems. Dashboard provides self-service.
Core Components
| Component | Responsibility | Technology |
|---|---|---|
| Merchant Onboarding | KYC, underwriting, activation | KYC APIs, underwriting engine |
| Payment Processing | Multi-rail transaction processing | Go/Java, rail connectors |
| Settlement | Fund transfer to merchants | Bank APIs, payout scheduling |
| Reconciliation | Cross-system matching | ETL, matching engine |
| Merchant Dashboard | Self-service portal | React/Node.js |
| Risk Management | Merchant risk monitoring | ML models, risk rules |
| Ledger | Double-entry financial ledger | PostgreSQL, event sourcing |
Detailed Technical Architecture
PSP technical architecture:
Merchant Lifecycle
Onboarding (KYC, underwriting) → Activation → Processing → Settlement → Monitoring → Offboarding.
Multi-Rail Processing
Cards, UPI, wallets, bank transfers. Rail abstraction with intelligent routing.
Settlement
T+1 for cards, T+0 for UPI. Automated payout scheduling. Escrow account management.
Reconciliation
Daily reconciliation across gateway, bank, and ledger. Exception handling for mismatches.
Merchant Dashboard
Transaction history, refunds, disputes, settlement reports, analytics.
Risk Management
Real-time merchant risk monitoring, fraud detection, chargeback tracking, risk actions.
APIs and Integration Patterns
PSP API patterns:
Merchant Onboarding
POST /merchants with business details and KYC documents. PSP handles verification and activation.
Payment Processing
POST /payments for transaction processing. Multi-rail support.
Settlement
GET /settlements for settlement reports. Automated payout scheduling.
Refunds
POST /payments/{id}/refund for full or partial refunds.
POST
/v1/merchantsOnboard a new merchant
Request
POST /v1/merchants
Authorization: Bearer sk_live_xxx
{
"business_name": "Acme Store",
"business_type": "individual",
"kyc": { "pan": "ABCDE1234F", "gst": "29ABCDE1234F1Z5" },
"bank_account": { "account_number": "1234567890", "ifsc": "HDFC0001234" },
"website": "https://acme.example.com"
}Response
{
"id": "merchant_26JAnXxXx",
"status": "pending_verification",
"activation_timeline": "24-48 hours"
}Data Architecture
PSP data architecture:
| Data | Purpose | Storage |
|---|---|---|
| Merchant DB | Merchant profiles, KYC, bank accounts | PostgreSQL |
| Transaction DB | Payment transactions | PostgreSQL (ACID) |
| Settlement DB | Settlement records, payouts | PostgreSQL |
| Ledger | Double-entry financial records | PostgreSQL |
| Reconciliation | Matching records, exceptions | PostgreSQL |
Security Architecture
PSP security:
PCI DSS
PSP must be PCI DSS compliant. Tokenization reduces scope. Annual audit.
Merchant KYC
Business verification, beneficial owner identification, risk assessment.
Transaction Security
Encryption, tokenization, fraud detection, 3DS for card payments.
Settlement Security
Escrow account protection, payout verification, fraud monitoring.
Regulatory Considerations
PSP regulatory requirements:
| Requirement | Description |
|---|---|
| RBI PA License (India) | Payment aggregator license with escrow, KYC, settlement rules |
| PCI DSS | Card data protection, annual audit |
| AML | Transaction monitoring, suspicious activity reporting |
| Data Protection | DPDP Act, GDPR compliance |
| Consumer Protection | Dispute resolution, grievance redressal |
Business Model Considerations
PSP business model:
| Revenue | Description | Typical Rate |
|---|---|---|
| MDR | Merchant discount rate | 1.5-3% cards, 0% UPI |
| Setup Fee | One-time merchant onboarding fee | Variable |
| Monthly Fee | Platform subscription | $50-$500/month |
| Value-Added | Fraud protection, instant settlement | Additional fees |
| Float | Interest on held settlements | 1-3 days float |
Vendor Landscape
Stripe
Global PSP with API-first design.
CardsUPIBank transfersBNPL
Razorpay
India-focused PSP.
UPICardsNet BankingEMI
Adyen
Enterprise PSP with direct acquiring.
CardsLocal methodsUnified commerce
Cashfree
Indian PSP with payouts and banking.
UPICardsPayoutsSplit
Real Enterprise Case Studies
PSP implementations:
RazorpayIndia · Fintech
Context: Indian PSP serving 10M+ merchants.
Problem: Enable Indian merchants to accept UPI and card payments with simple integration.
Architecture: API-first PSP with UPI, cards, net banking. Multi-rail processing. Automated settlement.
Technology: Go, PostgreSQL, Kafka, NPCI APIs, card network APIs
Outcomes: 10M+ merchants, billions in annual volume, rapid payment method integration.
Lessons: API-first design and developer experience drive adoption. Multi-rail support is essential in India.
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 PSP Platform
Objective: Design a complete PSP with merchant onboarding, processing, and settlement.
Scenario: Build a PSP for Indian merchants that supports UPI and card payments with automated settlement.
Tasks:
- Design merchant onboarding with KYC
- Design multi-rail payment processing
- Design settlement and payout system
- Design reconciliation engine
- Design merchant dashboard
- Design risk management
Deliverables: PSP architecture, API specification, settlement design, dashboard mockup.
Validation: Onboard merchant. Process payment. Verify settlement. Reconcile. Test dashboard.
Interview Questions
How does merchant settlement work in a PSP?
PSP collects payments into an escrow account. Settlement happens T+1 for cards, T+0 for UPI. Funds are transferred to merchant bank accounts. PSP deducts MDR and fees before settlement.
How do you handle merchant risk?
Underwriting at onboarding (business verification, risk assessment), real-time monitoring of transaction patterns, chargeback rate tracking, velocity checks. Risk actions: freeze, hold settlement, offboard.
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.
PSP
Payment Service Provider: platform enabling merchants to accept payments.
Underwriting
Process of evaluating and approving a merchant for payment processing.
Escrow
Account where PSP holds merchant funds before settlement.
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: PSP Architecture 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. PSP Architecture will be managed through AI agents with humans governing policy, security, and business alignment. Payments will be invisible, instant, and intelligent.
Key Takeaways
- A PSP enables merchants to accept payments through a single integration.
- Key components: onboarding, processing, settlement, reconciliation, dashboard.
- Multi-rail support (cards, UPI, bank transfers) is essential.
- RBI PA license required for PSPs in India.
- Merchant risk management is critical for PSP operations.