Machine Learning pathway increased my salary by 40%
Advanced Fintech & PaymentsEmbedded Finance & Payment Platform ArchitectureTopic 17
Payment Processing: Authorization, Capture, Clearing and Settlement
Complete payment processing lifecycle from authorization through settlement with architectural patterns
Quick Answer
Payment processing lifecycle consists of four stages: authorization (verify funds and place hold), capture (finalize the transaction), clearing (exchange transaction details between banks), and settlement (actual fund transfer). Authorization is real-time (1-3 seconds). Capture can be same-day or delayed. Clearing is batch or real-time. Settlement takes T+1 for cards, T+0 for UPI. Each stage has specific architectural requirements for state management, error handling, and reconciliation.
Learning Objectives
1Understand the complete payment processing lifecycle
2Design authorization, capture, clearing, and settlement systems
3Implement payment state machine with all states and transitions
4Handle exceptions, retries, and reconciliation
5Compare lifecycle across payment rails
Executive Summary
The payment processing lifecycle is the sequence of steps from payment initiation to final settlement. Understanding this lifecycle is fundamental to building payment systems. The four main stages are authorization, capture, clearing, and settlement.
Each stage has specific architectural requirements: authorization requires real-time processing, capture requires state management, clearing requires inter-bank communication, and settlement requires fund transfer and reconciliation.
This topic provides a comprehensive guide to the payment processing lifecycle, including state machine design, exception handling, and rail-specific differences.
What Is Payment Processing: Authorization, Capture, Clearing and Settlement?
The payment processing lifecycle is the sequence of stages a payment transaction goes through from initiation to final settlement: authorization (verify funds and place hold), capture (finalize the transaction), clearing (exchange transaction details between banks), and settlement (actual fund transfer). Each stage has specific participants, protocols, and timelines.
Why This Topic Matters
Understanding the payment lifecycle is essential for building reliable payment systems. Each stage has different failure modes, timing requirements, and reconciliation needs. Incorrect lifecycle management leads to failed payments, lost funds, and reconciliation issues.
For payment engineers and architects, the lifecycle is the foundation of payment system design. State machines, error handling, and reconciliation all revolve around the lifecycle stages.
Why It Matters in 2026+
In 2026, the payment lifecycle is evolving with real-time clearing and settlement. Traditional batch clearing is being replaced by real-time clearing in some rails. Settlement is moving from T+1 to T+0 or instant.
The lifecycle is also being extended with new stages: pre-authorization, partial capture, split settlement, and programmable settlement conditions.
Architecture Overview
Payment processing lifecycle:
Reference Architecture
Authorization
↓
Capture
↓
Clearing
↓
Settlement
↓
Reconciliation
Authorization verifies funds and places a hold. Capture finalizes the transaction. Clearing exchanges details between banks. Settlement transfers funds. Reconciliation verifies consistency.
Core Components
| Stage | Participants | Timeline |
|---|---|---|
| Authorization | Merchant, Acquirer, Network, Issuer | Real-time (1-3 seconds) |
| Capture | Merchant, Acquirer | Same-day or delayed |
| Clearing | Acquirer, Network, Issuer | Batch (daily) or real-time |
| Settlement | Acquirer, Issuer, Banks | T+1 cards, T+0 UPI |
| Reconciliation | Merchant, Acquirer, Bank | Daily |
End-to-End Lifecycle
Detailed payment lifecycle:
Lifecycle Flow
Customer Initiates
↓
Authorization Request
↓
Issuer Approves/Declines
↓
Hold Placed
↓
Merchant Ships/Provides Service
↓
Capture Request
↓
Clearing
↓
Settlement
↓
Funds Available
↓
Reconciliation
The customer initiates payment. Authorization request goes to issuer. If approved, a hold is placed on funds. Merchant provides service. Capture request finalizes the transaction. Clearing exchanges details. Settlement transfers funds. Reconciliation verifies.
Detailed Technical Architecture
Payment lifecycle technical architecture:
State Machine
Payment state machine: created → authorized → captured → cleared → settled. Exception states: failed, refunded, disputed.
Authorization
Real-time processing with sub-second response. Fraud check, balance verification, hold placement.
Capture
Finalize authorized transaction. Can be partial (e.g., restaurant tip adjustment). Same-day or delayed.
Clearing
Exchange transaction details between acquirer and issuer. Batch (daily) or real-time (newer rails).
Settlement
Actual fund transfer between banks. T+1 for cards, T+0 for UPI. Net settlement or gross settlement.
Reconciliation
Match transactions across merchant, acquirer, and bank. Identify and resolve discrepancies.
APIs and Integration Patterns
Payment lifecycle APIs:
Authorization
POST /payments to authorize. Response includes authorization code and hold amount.
Capture
POST /payments/{id}/capture to finalize. Can specify capture amount (partial capture).
Refund
POST /payments/{id}/refund to return funds. Full or partial refund.
Void
POST /payments/{id}/void to cancel an authorized but not captured payment.
POST
/v1/paymentsAuthorize a payment
Request
POST /v1/payments
Idempotency-Key: auth_001
Authorization: Bearer sk_live_xxx
{
"amount": 4999,
"currency": "INR",
"payment_method": "card",
"card": { "token": "tok_xxx" },
"capture": false
}Response
{
"id": "pay_26JAnXxXx",
"status": "authorized",
"authorization_code": "AUTH123",
"authorized_amount": 4999
}POST
/v1/payments/{id}/captureCapture the authorized payment
Request
POST /v1/payments/pay_26JAnXxXx/capture
Idempotency-Key: cap_001
{
"amount": 4999
}Response
{
"id": "pay_26JAnXxXx",
"status": "captured",
"captured_amount": 4999
}Data Architecture
Payment lifecycle data:
| Data | Purpose | Storage |
|---|---|---|
| Transaction State | Current state in lifecycle | PostgreSQL (ACID) |
| Authorization | Auth code, hold amount, expiry | Transaction DB |
| Capture | Capture amount, timestamp | Transaction DB |
| Clearing | Clearing batch, network reference | Transaction DB |
| Settlement | Settlement amount, date, bank ref | Settlement DB |
| Reconciliation | Match status, exceptions | Reconciliation DB |
Security Architecture
Lifecycle security:
Authorization Security
3DS for card-not-present, fraud scoring, velocity checks.
Capture Security
Idempotency to prevent duplicate captures. Amount validation.
Settlement Security
Escrow account protection, bank transfer verification.
Reconciliation Security
Audit trail, immutable records, exception investigation.
Business Model Considerations
Lifecycle economics:
| Stage | Cost | Timing |
|---|---|---|
| Authorization | No cost (auth only) | Real-time |
| Capture | Interchange + scheme fees | Same-day or delayed |
| Clearing | Scheme fees | T+1 batch |
| Settlement | Interchange transferred | T+1 cards, T+0 UPI |
Real Enterprise Case Studies
Payment lifecycle implementations:
StripeUSA · Fintech
Context: Global payment processing platform.
Problem: Provide clean API for payment lifecycle management.
Architecture: REST API with separate endpoints for authorize, capture, refund, void. State machine management.
Technology: Ruby, Go, PostgreSQL
Outcomes: Millions of merchants using lifecycle APIs.
Lessons: Clean API design for lifecycle stages is essential. State machine must be well-defined.
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
Build a Payment State Machine
Objective: Design and implement a payment state machine with all lifecycle stages.
Scenario: Build a payment processing system with authorization, capture, clearing, and settlement stages.
Tasks:
- Design payment state machine with all states and transitions
- Implement authorization API
- Implement capture API (full and partial)
- Implement clearing and settlement
- Implement reconciliation
- Handle exceptions and edge cases
Deliverables: State machine design, API implementation, reconciliation logic.
Validation: Process payment through all stages. Verify state transitions. Test partial capture. Verify reconciliation.
Interview Questions
What is the difference between authorization and capture?
Authorization verifies funds are available and places a hold, but does not transfer funds. Capture finalizes the transaction and triggers fund transfer. This two-step process is useful when the final amount may change (e.g., hotel, gas station).
What is partial capture?
Partial capture captures less than the authorized amount. Useful when the actual charge is less than the authorized amount (e.g., restaurant where tip is added after authorization, or when some items are out of stock).
How does settlement differ between cards and UPI?
Card settlement is T+1 (funds transferred next business day). UPI settlement is T+0 (instant). Card settlement involves clearing (exchanging details) and settlement (fund transfer). UPI does both in real-time.
Frequently Asked Questions (53)
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.
Authorization
Verification that funds are available, placing a hold on the funds.
Capture
Finalization of an authorized transaction, triggering fund transfer.
Clearing
Exchange of transaction details between acquiring and issuing banks.
Settlement
Actual transfer of funds between banks to complete a transaction.
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 Processing Lifecycle 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 Processing Lifecycle will be managed through AI agents with humans governing policy, security, and business alignment. Payments will be invisible, instant, and intelligent.
Key Takeaways
- The payment lifecycle consists of authorization, capture, clearing, and settlement.
- Authorization is real-time; settlement takes T+1 for cards, T+0 for UPI.
- A well-defined payment state machine is essential for reliable processing.
- Partial capture enables flexible amount finalization.
- Reconciliation verifies consistency across all lifecycle stages.