Tarun Killamsetty

What Payments Infrastructure Actually Does

A short field guide for people outside the industry

· Updated · 2 min read · 306 words

People outside the industry often assume “payments” means moving money from one account to another. That’s the visible part. Most of the actual work is invisible: reconciling who owes whom, deciding what happens when something fails halfway through, and proving after the fact that a transaction was authorized, settled, and recorded correctly.

The three problems underneath every payment

  1. Authorization — was this transaction allowed to happen at all?
  2. Settlement — has value actually moved between the correct parties?
  3. Reconciliation — can every party independently verify that the first two happened correctly?

A system can get authorization right and still fail on reconciliation, and a lot of “payments outages” are really reconciliation failures that only become visible days later.

A simplified state machine

Here’s a stripped-down version of how a transaction might move through states in code:

type TransactionState =
  | 'initiated'
  | 'authorized'
  | 'settled'
  | 'reconciled'
  | 'failed';

function nextState(current: TransactionState, event: string): TransactionState {
  if (current === 'initiated' && event === 'approve') return 'authorized';
  if (current === 'authorized' && event === 'clear') return 'settled';
  if (current === 'settled' && event === 'verify') return 'reconciled';
  return 'failed';
}

The interesting failures happen between states, not within them — a transaction that is authorized but never reaches settled, for instance.1

Why this is harder than software alone

Layer What it handles Typical failure mode
Network rails Moving the message between banks Timeouts, message loss
Ledger Recording who owns what Double-counting, drift
Compliance Who is allowed to transact False declines, fraud

None of these layers is purely a technology problem. Each one is a technology problem wrapped around a legal and financial one, which is why payments teams tend to include people who think about law and accounting as much as people who write code.

Use idempotency keys liberally — they are one of the few tools that make retries safe across all three layers at once.

Footnotes

  1. This is sometimes called a “stuck” or “orphaned” transaction, and resolving it usually requires manual review rather than automated retries. ↩