Design a Unified Payments Interface

The ask

Any bank customer can pay any other bank customer. The rail is shared, so no pair of banks builds a private link.

Money moves from account to account at once, day and night. There is no waiting for a settlement window to spend it.

The payer approves each payment with a secret code on a phone. Approval and movement are part of one flow.

The central switch routes requests between banks. Banks keep the accounts and the money.

Estimate the scale

The rail carries 10,000,000,000 transactions in a 30-day month.

10,000,000,000 / 30 = 333,333,333 transactions a day.

333,333,333 / 86,400 = 3,858 transactions per second on average.

Each transaction passes through the central switch and touches two banks. 333,333,333 x 2 = 666,666,666 bank hops a day.

The switch itself stores little. Its load is routing, checks and answers at a high rate.

API and data

The operations are pay, request money, check status and resolve a payment address.

Resolve takes a payment address and returns the bank that holds the account. The account number itself never leaves that bank.

A pay request carries the payer address, the payee address, an amount and a unique transaction reference.

The reference works as an idempotency key. A retry with the same reference returns the stored result.

Each bank keeps its own ledger for its accounts. The switch keeps a record of every routed transaction and its state.

High-level design

A phone app sends the pay request to the payer bank. The payer bank checks the account, the balance and the approval code.

The payer bank sends the request to the central switch. The switch reads the payee address and routes the request to the payee bank.

The payee bank credits the payee account and answers the switch. The switch confirms the result to both banks.

Both phones then show the outcome. A confirmation failure leaves the stored state ready for a status check.

Deep dive: the central switch

The switch is a router with a memory. It finds the right bank, passes the request and records the state of each hop.

Routing uses the address registry. The registry maps each payment address to one bank, and banks update it when accounts move.

The switch adds no money logic of its own. Balances, holds and ledger entries stay inside the banks.

Many switch copies run behind a load balancer. The transaction reference keeps one request tied to one record across copies.

A slow bank gets a short deadline. A missed deadline marks the transaction as pending instead of guessing the result.

Deep dive: debit and credit as one act

The payer account is debited at the payer bank. The payee account is credited at the payee bank.

A failure between debit and credit is the hardest seam. The debit must not stand alone.

Each bank records its step before answering. A compensating action returns a debit when the credit cannot complete.

Status reads settle every doubt. Payer and payee can ask the switch for the stored state at any time.

Reconciliation across the two banks and the switch runs every day. A mismatched transaction becomes a case for people.

Names and privacy

A payment address is easy to say and easy to type. A shop can print one and a friend can share one.

The address reveals no bank details. A stranger with an address can send money and cannot take money.

Requests for money flip the flow. The payee asks, the payer still approves, and no approval means no movement.

A name check shows the account holder name before paying. The payer can stop on a wrong name.

Failures and limits

Per-payment and daily limits cap damage from a stolen phone. Banks set the caps and the switch enforces shared ones.

A fraud check at the payer bank takes payment facts and returns a risk score. A high score can block the payment for review.

An offline bank queues incoming credits for a short time. Senders see a pending state instead of a false failure.

Every hop logs its step with the transaction reference. One reference rebuilds the whole story of a payment.

Evaluation and trade-offs

A shared rail gives reach. One account can pay every other account on the rail.

The centre is also a shared risk. The switch needs strong replication and careful capacity for peaks.

Banks keep control of accounts and ledgers. The rail standardises the path between them.

The design trades bank freedom for a common shape. Every bank follows the same request, states and answers.

A payment in steps