Lesson 1 · Foundations · Both · 12 min
What Is a Payment? Auth, Clearing, Settlement
Separate the customer experience of 'paid' from the three rails underneath: authorization, clearing, and settlement — and why those stages matter for risk, cash, and product design.
Objectives
- ▸Define a payment as an instruction plus value transfer across accounts
- ▸Distinguish authorization, clearing, and settlement with concrete timing
- ▸Map who holds risk between auth success and final settlement
- ▸Explain why 'success' in the UI can still reverse later
A payment is a signed (or authenticated) instruction to move value from a payer account or instrument to a payee. The customer sees a green check; the industry sees a chain of messages, provisional credits, and finality rules. Product teams that conflate UX confirmation with irrevocable settlement create chargeback, reconciliation, and cash-forecasting bugs.
- Payer: person or entity funding the transfer (cardholder, account holder, wallet user)
- Payee: merchant, beneficiary, billers, or another consumer
- Instrument: bank account, card, UPI VPA, wallet balance, mandate
- Rail / scheme: the network and rulebook that carries the instruction (UPI, NEFT, Visa, ACH, SWIFT)
Design three states in your domain model: Authorized / Accepted, Cleared / Matched, Settled / Final. Map every webhook and status code onto those states — not onto a single boolean 'paid'.