Pick a depth. Each prompt opens in your AI pre-loaded with the lesson. Click a row to preview the prompt.
Real-time payment rails are the new normal in many countries — UPI in India processes ~14 billion transactions/month; FedNow in the US, Faster Payments in the UK, Pix in Brazil all run on similar models. They settle in seconds, are largely irreversible, and have transformed consumer fintech. Understanding the model is essential for any modern product.
Anatomy of a real-time payment.
Actors:
Payer: User with a bank account at any bank, app of their choice
Payee: Merchant or another user
PSP (Payer): Payment Service Provider for payer (PhonePe, Google Pay, Paytm)
PSP (Payee): PSP for payee
Banks: Payer's bank, payee's bank
NPCI: National Payments Corp of India (the switch/router)
Flow (sub-second):
1. User types payee's VPA (Virtual Payment Address: user@bank.com style)
2. App sends "collect-from" or "send-to" intent to payer's PSP
3. PSP routes via NPCI to payer's bank
4. Bank checks balance, debits payer's account, returns success to NPCI
5. NPCI credits payee's bank account (real-time net settlement)
6. Payee's bank notifies payee's PSP
7. PSP shows "received" to payee
Total elapsed time: 2-15 seconds
Comparison to card rails:
Faster: seconds vs minutes-hours
Cheaper: free or near-zero vs 2-3%
Less reversible: most networks have NO chargeback equivalent
Compliance:
AML/CFT: real-time means real-time monitoring requirements
Limits: per-day, per-transaction (typically ~₹100k = $1200 default in India)
KYC: full KYC required to onboard a bank account; transaction-level less strict
Why design changes for instant rails:
Order: no "pending" state — money has moved
Refund: must be a NEW payment in reverse, not a "reversal"
Fraud: minutes-to-react instead of days; ML monitoring critical
UX: optimistic UI is now the actual truth, not a fake-it pattern