Payments

Learning outcomes

Every fintech product that touches money eventually comes down to one question: how do I get a specific amount of value from one party to another, reliably, and know for certain when it is done. That movement runs over a payment rail, and the rails differ in ways that are not cosmetic. They differ in how fast money arrives, what it costs, whether the transfer can ever be undone, and at what exact instant the receiver truly owns the funds. Pick the wrong rail and you either bleed money on fees, expose yourself to fraud you cannot claw back, or promise customers a speed the rail cannot deliver. Understand the rails as a family and most of payments engineering stops being a maze of acronyms and becomes a small set of trade-offs you can reason about.

After studying this page, you can:

• Explain what a payment rail is, why several exist, and why no single rail is best for every job.
• Distinguish push from pull payments and say which rails are which, and why that distinction governs fraud, returns, and authorization.
• Separate clearing from settlement, explain why final settlement happens in central bank money, and say what finality means and when it is reached on each rail.
• Compare ACH, Fedwire, CHIPS, RTP, FedNow, and card networks on speed, cost, finality, and reversibility, and choose the right one for a given use case.
• Trace a card payment through authorization, clearing, and settlement across the four-party model, and explain where the money and the fees actually move.
• Explain returns, reversals, and chargebacks, who initiates each, and the window in which each is possible.
• Design the core of a payment system: how to ledger money in flight, model payment state, enforce idempotency and exactly-once effects, and handle timeouts.
• Name the dominant failure modes (duplicates, stuck payments, fraud, reconciliation breaks) and the controls that catch each one.

Before we dive in

You do not need prior payments knowledge. We will define each term on first use and build up from a single transfer.

A payment is the transfer of a specific amount of value from a payer (the party whose account is debited, also called the sender or originator) to a payee (the party whose account is credited, also called the receiver or beneficiary). A payment rail is the shared system of rules, messaging, and settlement plumbing that actually carries that transfer between banks. A bank here means a regulated depository institution that holds accounts; most non-bank fintechs reach the rails through a partner bank or a processor that has direct access.

A few more terms we will lean on. Clearing is the exchange of payment instructions and the calculation of who owes whom. Settlement is the actual movement of funds that discharges those obligations. Finality is the moment a payment becomes irrevocable, so the receiver can spend the money with no risk of it being pulled back. Central bank money is a balance held at the central bank (in the United States, the Federal Reserve); it is the most certain form of money because it cannot fail the way a commercial bank can. Float is value that has left one party but not yet arrived at the other, money in flight. A processor is a company that handles the technical movement of payments on behalf of merchants or banks. Hold the picture of value leaving an account, traveling through a rail, and arriving in another account, and watch one question follow the money the whole way: at this instant, who really owns it, and can it still be reversed.

Mental Model

The wrong model, and almost everyone starts here, is that a payment is a single instantaneous transfer: money leaves my account and at the same moment appears in yours, like handing over cash. The app shows the balance changing, so it feels atomic and immediate. This model quietly assumes the two events happen together and that once you see the money it is yours.

That model breaks on every rail except physical cash. A payment is not one event; it is at least two separated in time: a clearing step that says who should pay whom, and a settlement step that actually moves the money between banks, often hours or days later. In between, the funds are float: they have left the payer’s view but are not yet final to the payee. Worse, the moment the payee can spend the money (funds availability) is usually different from the moment the payment can no longer be reversed (finality). A bank may give you provisional access to funds before settlement is final, taking a calculated risk, which is exactly why a deposit can be clawed back days later.

Here is the model to hold instead. Picture a payment as a parcel moving through a courier network, not a hand-to-hand exchange. When you send it, you get a tracking number, not delivery. The parcel sits in a sorting facility (clearing), travels overnight (settlement), and is only truly delivered when it is signed for (finality). Different couriers offer different guarantees: one is cheap but slow and lets the sender recall the parcel for days (ACH), one is expensive but delivered within hours and impossible to recall once sent (a wire), one delivers in seconds and is final the instant it lands (a real-time rail). The question that follows the parcel the whole way is the one that matters in payments: right now, where is the value, who can still stop it, and when does it become irreversibly the receiver’s. Keep that question in mind and every rail below becomes a different answer to it.

Breaking it down

The core teaching runs in fourteen steps. The first six build up the rails one at a time, from first principles through the major US systems. Steps seven through ten cover cards and the messaging that ties everything together. The last four rebuild all of it the way an engineer must, because the rails are institutional but the systems that drive them are code, and the failure modes are yours to handle.

1. What a payment actually is and why rails exist

Start from the simplest case. You hand a friend a twenty dollar bill. That is a complete payment: value moved, it is final the instant the bill changes hands, no third party was involved, and there is no way to reverse it short of asking for it back. Cash has properties every electronic rail spends enormous effort trying to approximate: it is instant, final, and settles peer to peer with no intermediary.

The problem is that cash does not scale and does not work at a distance. You cannot hand a bill to a supplier in another city, you cannot pay a recurring bill automatically, and a business cannot hold or audit large sums in paper. So almost all value moves as balances in bank accounts instead. But the moment money lives as a bank balance, a payment between two people is really a payment between two banks: my bank must reduce my balance and your bank must increase yours, and the two banks must somehow settle up with each other. Two banks could call each other and reconcile one payment at a time, but with millions of banks and billions of payments that does not work. The answer is shared infrastructure: a rail that standardizes the message format, the timing, the rules for reversals, and crucially the way banks settle their net obligations through a common settlement agent, almost always the central bank.

flowchart LR
  P["Payer"] --> PB["Payer's bank"]
  PB --> R["Payment rail<br/>(rules, messaging,<br/>net obligations)"]
  R --> PEB["Payee's bank"]
  PEB --> PE["Payee"]
  R -.settles through.-> CB["Central bank<br/>(settlement agent)"]

Several rails exist because the requirements genuinely conflict and no single design optimizes all of them at once. Some payments are tiny and frequent (a coffee, a payroll run for thousands of employees) and need to be cheap above all, even if slow. Some are huge and time-critical (a house closing, a bank funding another bank) and need to be final within minutes, where the fee is trivial next to the amount. Some need to happen in seconds at any hour (a gig worker cashing out at midnight). And some need the buyer to be protected against a seller who never ships (a card purchase online). You cannot get cheap, instant, final, and reversible all at once: cheap batch processing is slow, instant finality forecloses reversibility, and buyer protection requires a reversible pull mechanism that batch rails are built for and instant rails deliberately avoid. The rails are different points on those trade-offs, and choosing among them is the core skill.

The rest of this page unpacks each of these and then shows how to build the systems that drive them. But hold the frame from this section: a rail exists to let many banks settle many payments through shared rules and a common settlement agent, and the rails differ because cheap, fast, final, and reversible cannot all be maximized together.

2. Push versus pull and who can move whose money

Before any specific rail, internalize one distinction that governs fraud, returns, and authorization across all of them: the difference between a push payment and a pull payment.

A push payment (also called a credit transfer) is initiated by the payer. You tell your own bank to send money out of your account to someone else. Because you control the account the money leaves, a push is intrinsically safer for the payer: nobody can reach into your account and take money without you starting the transfer. A wire, an ACH credit, and every real-time rail payment are pushes. The risk on a push sits with the payer, who must get the destination right, because once final the money is gone.

A pull payment (also called a debit transfer) is initiated by the payee, who reaches into the payer’s account to take the money, having been given authorization to do so. When you set up a utility to autopay from your checking account, or swipe a card, the merchant pulls funds from you. Pulls are enormously convenient (the payer does nothing each cycle) but they invert the risk: someone other than the account holder can move money out of the account, so pulls require a strong authorization framework and a way to dispute and reverse unauthorized or wrong pulls. ACH debits and card transactions are pulls. This is precisely why cards and ACH debits have elaborate return and chargeback rights, and why instant rails, which are final on receipt, are push only: you cannot safely give a stranger an irreversible pull on your account.

sequenceDiagram
  participant Payer
  participant PayerBank as Payer's bank
  participant PayeeBank as Payee's bank
  participant Payee
  Note over Payer,Payee: PUSH (credit) initiated by payer
  Payer->>PayerBank: Send $100 to Payee
  PayerBank->>PayeeBank: Credit transfer
  PayeeBank->>Payee: Funds credited
  Note over Payer,Payee: PULL (debit) initiated by payee
  Payee->>PayeeBank: Collect $100 from Payer (with authorization)
  PayeeBank->>PayerBank: Debit request
  PayerBank->>Payer: Account debited

The push or pull nature of a rail explains most of its other properties. Pull rails need reversibility because the account holder did not initiate the movement and must be able to dispute it, so they come with returns and chargebacks and longer dispute windows. Push rails put the responsibility on the sender and tend toward finality, because the sender chose to send. When you reach for a rail, ask first: who is initiating, and therefore who bears the risk and needs the protection. That single question predicts whether the rail will be reversible, how it handles authorization, and where fraud tends to land.

3. Clearing versus settlement and central bank money

This is the distinction that the naive mental model misses, and it sits underneath every rail. Clearing and settlement are two different jobs, separated in time.

Clearing is the exchange of payment instructions and the working out of obligations: my bank and your bank (often via the rail operator) agree that bank A owes bank B a net amount as a result of all the payments that flowed between their customers. No money has actually moved between the banks yet; they have only computed who owes whom. Settlement is the actual transfer of funds between the banks that discharges those obligations. The payment is not truly complete, in the sense of value irrevocably changing hands at the bank level, until settlement.

There are two settlement styles, and the choice drives a rail’s speed, cost, and risk. In net settlement, the rail accumulates all the payments over a period, nets them down to a single figure per bank pair (or per bank against the whole system), and settles only the net at the end of a cycle. This is hugely efficient: thousands of payments collapse into one transfer, so banks move far less money and the rail is cheap. The cost is settlement risk, also called Herstatt risk: between clearing and settlement, a bank could fail still owing its net amount, and the payments it received have already been provisionally passed to customers. ACH and CHIPS are netting systems. In gross settlement, every payment is settled individually and immediately, one at a time, in full. This eliminates settlement risk (each payment is final the instant it settles) but moves far more money and demands that banks have the funds on hand right then. Fedwire is a real-time gross settlement, or RTGS, system.

flowchart TB
  subgraph net["Net settlement (ACH, CHIPS)"]
    N1["Many payments collected<br/>over a cycle"] --> N2["Net each bank's position<br/>(who owes what, on net)"]
    N2 --> N3["Settle only the net amount<br/>once per cycle"]
  end
  subgraph gross["Gross settlement (Fedwire RTGS)"]
    G1["Each payment arrives"] --> G2["Settle it individually,<br/>in full, immediately"]
    G2 --> G3["Final the instant it settles<br/>(no settlement risk)"]
  end

Now the part that ties it together: why settlement ultimately happens in central bank money. When bank A pays bank B, the only fully riskless way to settle is to move a balance that cannot itself fail. A commercial bank can become insolvent, so a claim on a commercial bank carries credit risk. A balance at the central bank does not, because the central bank issues the currency and cannot run out of it. So every major rail settles, in the end, by moving reserve balances that banks hold at the central bank. Fedwire moves Fed balances directly. ACH and FedNow settle to Fed accounts. Even CHIPS, a private netting system, settles its final positions through Fedwire in central bank money. This is the bedrock: customer-facing payments may run over many rails and many intermediaries, but underneath, the banks square up with each other in central bank money, because that is the one form of settlement with no counterparty to fail. When you hear that a payment is final, what makes it final is almost always that it has settled in central bank money.

4. ACH the batch workhorse

ACH, the Automated Clearing House, is the cheap, high-volume backbone of US account-to-account payments. It is a batch system: rather than processing each payment the instant it is submitted, ACH collects payments into files, processes them in scheduled windows, and settles in batch. In the United States the network is operated by the Clearing House and the Federal Reserve, and the rules are set by Nacha.

ACH carries both flavors from section two. An ACH credit is a push: the originator sends money out (payroll is the classic example, where an employer pushes wages to thousands of employees). An ACH debit is a pull: the originator collects money from another account it has been authorized to debit (a utility autopay, a subscription, a lender collecting a loan payment). The party that starts the transaction is the Originator, working through its bank, the ODFI (Originating Depository Financial Institution); the other side is the Receiver at the RDFI (Receiving Depository Financial Institution). The ODFI submits entries to an ACH Operator (the Fed or the Clearing House), which sorts them and delivers them to the RDFIs, and settlement happens on the schedule.

Traditional ACH settles on the next business day or two; Same Day ACH added intraday windows so eligible payments settle the same business day, with a per-transaction dollar cap that Nacha has raised over time (it reached $1,000,000 per Same Day ACH entry in 2022). ACH does not run on weekends or bank holidays, because its settlement windows align to the banking day. The cost per item is very low, often a fraction of a cent to a few cents at the network level, which is what makes it the right rail for high-volume, non-urgent flows.

The defining engineering reality of ACH is returns. Because an ACH debit is a pull and the original instruction can be wrong or unauthorized, the RDFI can send the entry back with a return code (Nacha calls them return reason codes, the R-codes). R01 is insufficient funds, R02 is account closed, R03 is no account, and so on, up through R10 for an unauthorized debit. The critical, counterintuitive part: a return can arrive after you have already given the customer the money. For most administrative returns the RDFI has two banking days, but for an unauthorized consumer debit the consumer has up to 60 calendar days to dispute, and the return can land that late. This is the single fact that shapes how you build on ACH: an ACH credit you received is not final money for days, and an ACH debit you originated can bounce or be disputed long after you treated it as paid.

5. Wires Fedwire and CHIPS for large value

When a payment is large and must be final today, you use a wire. A wire transfer is a push, real-time (or near real-time), high-value credit transfer that, once settled, is final and effectively irreversible. There is no return mechanism like ACH’s: if you wire money to the wrong place, you do not get it back by right; you have to ask the receiving bank to send it back voluntarily, and if the money is gone, it is gone. This finality is the whole point. A title company at a real estate closing wires the funds precisely because the seller needs certainty that the money is theirs, today, with no clawback.

The United States has two large-value wire systems. Fedwire, operated by the Federal Reserve, is a real-time gross settlement system: each wire is settled individually and immediately in central bank money, so it is final the instant it completes. Fedwire is where banks settle the largest and most time-critical obligations, and it is the ultimate settlement layer many other rails rely on. CHIPS, the Clearing House Interbank Payments System, is a privately operated system run by the Clearing House, used heavily for large-value and cross-border dollar payments. CHIPS is a netting system: it continuously nets payments through the day and settles the net positions, which is far more liquidity-efficient than settling every payment gross. Where Fedwire trades liquidity for instant finality, CHIPS trades a small amount of intraday timing for dramatically less money moved. Both ultimately settle in central bank money, CHIPS by squaring its final balances through Fedwire.

flowchart LR
  subgraph fw["Fedwire (RTGS)"]
    F1["Wire arrives"] --> F2["Settled individually<br/>in full, in Fed money"]
    F2 --> F3["Final immediately,<br/>irreversible"]
  end
  subgraph ch["CHIPS (netting)"]
    C1["Wires throughout the day"] --> C2["Continuously netted"]
    C2 --> C3["Net positions settled<br/>via Fedwire in Fed money"]
  end

The trade-off against ACH is stark and instructive. A wire costs a lot (commonly $15 to $35 to the customer, sometimes more for the receiver) and is final and irreversible; an ACH transfer costs almost nothing and is slower and reversible. The fee is not arbitrary: a wire consumes intraday liquidity and central bank settlement capacity for a single payment, and it carries operational weight because there is no undo. You pay for finality and immediacy. The rule of thumb is that wires are for large, urgent, certain transfers where the fee is negligible against the amount and finality is worth paying for, and ACH is for everything routine where cost and reversibility matter more than speed. Note also that because wires are irreversible pushes, they are the favorite of fraudsters running business email compromise and real estate wire scams: there is no chargeback, so a tricked sender has almost no recourse. The same finality that makes wires valuable makes them dangerous when the instruction is wrong.

6. Real-time rails RTP and FedNow

For decades the gap in US payments was obvious: ACH was cheap but slow and batch-bound, wires were fast and final but expensive and business-hours-bound, and nothing moved small-value money instantly, around the clock, with immediate finality. The real-time rails fill that gap. The RTP network, launched by the Clearing House in 2017, was the first new US core payment rail in decades. FedNow, the Federal Reserve’s instant payment service, launched in July 2023. Both deliver the same core promise: a payment that completes in seconds, any time of day, every day of the year, and is final on receipt.

Two design choices define these rails. First, they are credit-push only: the payer pushes money to the payee, and there is no pull. This is a deliberate fraud and risk decision, following directly from section two. Because the payment is final the instant the payee’s bank accepts it, you cannot safely let a third party pull irreversibly from your account, so the rails simply do not allow debits. To support bill-pay-style flows, they add Request for Payment (RfP): the payee sends a request, but the payer must approve it and push the money, keeping control on the side of the account being debited. Second, settlement is built for instant finality. RTP requires participating banks to prefund a joint account at the Fed and settles against those balances; FedNow settles directly in banks’ Fed master accounts. Either way, the funds are real central bank money positioned so the payment can be final immediately.

The trade-offs are the inverse of ACH’s. Real-time rails give you speed and immediate availability and finality, at the cost of reversibility: like a wire, once an instant payment lands, there is no built-in undo, so a mistaken or fraud-induced push is hard to recover. They are 24/7, so your systems must be too: there is no overnight batch window to lean on, no weekend to reconcile in, and a stuck or duplicated instant payment is a live incident at 3 a.m. on a Sunday. And because they are newer, reach is still growing as more banks connect. The strategic point for a builder: real-time rails are the right choice when immediate, final availability is the product (a gig worker cashing out, an instant account-to-account transfer, a time-sensitive disbursement), and you accept that you trade away the reversibility that ACH and cards give you.

7. The four-party card model

Cards look simple to a cardholder (tap and go) and are the most structurally complex consumer rail underneath. The dominant structure is the four-party model, and naming the four parties is the key that unlocks everything about cards, including why they cost merchants what they do.

The four parties are: the cardholder (the consumer paying), the merchant (the business being paid), the issuer (the cardholder’s bank, which issued the card and carries the cardholder’s account and credit line), and the acquirer (the merchant’s bank, which holds the merchant account and accepts card payments on the merchant’s behalf). The card network (Visa, Mastercard) sits in the middle as the switch and rule-maker connecting issuers and acquirers; it does not lend to consumers or hold merchant accounts itself, which is why this is called a four-party (or open-loop) model. A processor is the technical operator that handles the message traffic for the merchant or acquirer side, and often for the issuer side too. American Express and Discover historically run a three-party (closed-loop) model, where the network is also the issuer and acquirer, but the four-party model is the one to understand first because it is dominant and its economics drive the industry.

flowchart LR
  CH["Cardholder"] -->|pays| M["Merchant"]
  M --> ACQ["Acquirer<br/>(merchant's bank)"]
  ACQ --> NET["Card network<br/>(Visa / Mastercard)"]
  NET --> ISS["Issuer<br/>(cardholder's bank)"]
  ISS -.bills.-> CH
  NET -.sets interchange<br/>and rules.-> NET

The economics are the reason the structure exists, and they explain the fees a merchant pays. A card payment is a pull (the merchant pulls funds via the network from the cardholder’s issuer), and the merchant pays a merchant discount, the total cost of accepting the card. The largest component is interchange, a fee set by the network that flows from the acquirer to the issuer on each transaction (commonly a percentage plus a fixed amount, varying by card type and channel). Interchange is the issuer’s compensation for funding the transaction, taking credit and fraud risk, and providing cardholder rewards, which is why premium rewards cards carry higher interchange. On top sit network assessments (the network’s own fee) and the acquirer’s and processor’s markup. Net, the merchant commonly pays somewhere around 1.5 to 3.5 percent of the sale. That cost buys the merchant guaranteed payment (once authorized and within the rules) and access to billions of cardholders, and it funds the issuer’s rewards and risk-taking. Understanding that interchange flows acquirer to issuer, set by the network, explains nearly every fee debate in cards.

8. Authorization clearing and settlement on cards

A card transaction is not one step; it is three, spread over time, and conflating them is a classic source of bugs. The three steps are authorization, clearing, and settlement, and the money moves at a different step than most engineers assume.

Authorization happens in real time at the moment of purchase, in seconds. The merchant (through its acquirer and the network) asks the issuer: is this card valid and are funds or credit available for this amount. The issuer runs fraud and risk checks and returns an approve or decline. On approval, the issuer places a hold (an authorization hold) on the cardholder’s available balance for the amount, but no money has moved yet. This is the part that surprises people: authorization is a promise and a reservation, not a transfer. The hold reduces the cardholder’s available credit or balance and guarantees the merchant will be paid if it completes the transaction within the rules and time limits.

Clearing happens later, usually that night or the next day, when the merchant submits the transaction for capture (often in a batch). Capture turns the authorization into a request to actually be paid; the acquirer sends clearing records through the network to the issuers. This is where the final amounts, fees, and interchange are exchanged as data. Settlement is the actual movement of money: the network calculates net positions, the issuers pay the acquirers (net of interchange) through the network’s settlement process, and the acquirer credits the merchant, typically one to three business days after the sale. So the cardholder sees a hold at authorization, sees the charge post at clearing, and the merchant receives funds at settlement, days after the customer walked out.

The separation of these three steps has real engineering consequences. The authorized amount and the captured amount can differ: a restaurant authorizes the bill and captures it plus a tip; a gas pump authorizes a placeholder amount and captures the actual fuel; a hotel authorizes an estimate and captures the final folio. A hold can expire if not captured in time, releasing the cardholder’s funds and forcing a re-authorization. And because settlement is net and delayed, the merchant carries the gap between making the sale and receiving the money, which is why funding speed (and reserves an acquirer may hold against chargebacks) is a real business concern. Model authorization, capture, and settlement as distinct states with their own timeouts, not as one event.

9. Returns reversals and chargebacks

Reversibility is where the rails differ most, and the words for undoing a payment are not interchangeable. Three mechanisms matter, each from a different rail and initiated by a different party.

A return is an ACH concept (section four). The RDFI sends an entry back because it cannot be applied (no account, account closed, insufficient funds) or because it was unauthorized. The window ranges from two banking days for administrative reasons to 60 calendar days for an unauthorized consumer debit. A return is initiated by the receiving bank on behalf of, or because of, the account holder. A reversal is a correction initiated by the originator: Nacha rules let an originator reverse an erroneous ACH entry (a duplicate, a wrong amount, a wrong account) within a tight window, typically within five banking days and promptly after discovery. A reversal is you undoing your own mistake, not a dispute.

A chargeback is a card concept and the most consequential of the three. The cardholder disputes a transaction with their issuer (I did not make this purchase, the goods never arrived, the amount is wrong), and the issuer pulls the funds back from the merchant through the network, reversing the payment. The merchant can fight it by submitting evidence (representment), and the networks define a structured dispute lifecycle with defined reason codes and time limits. Chargeback windows are long, commonly up to 120 days from the transaction or the expected delivery date, and can stretch further in some scenarios. The cost to the merchant is not just the refunded amount: there is a chargeback fee, and a merchant with an excessive chargeback ratio can be placed in a network monitoring program and ultimately lose the ability to accept cards. This is the buyer protection that justifies cards’ high cost: the cardholder gets a powerful, long-lived right to reverse, and the merchant and acquirer bear the risk.

stateDiagram-v2
  [*] --> Settled: payment completes
  Settled --> Disputed: cardholder files chargeback
  Disputed --> Represented: merchant submits evidence
  Represented --> Won: issuer accepts evidence
  Represented --> Lost: issuer upholds dispute
  Disputed --> Lost: merchant does not respond
  Won --> [*]
  Lost --> [*]
  note right of Disputed
    Funds are pulled back from the
    merchant while the dispute is open.
  end note

The contrast across the rails is the lesson. Wires and instant rails are essentially irreversible: there is no return, no chargeback, only a voluntary request to send the money back. ACH is reversible within bounded windows by return or originator reversal. Cards are the most reversible, with long, consumer-friendly chargeback rights. Reversibility is not free: it is exactly what makes a rail safe for the payer and risky (and expensive) for the payee. When you choose a rail, you are also choosing who can undo the payment and for how long, and that choice should match where you want the risk to sit. A marketplace paying out to sellers wants finality (instant or wire) so sellers trust the money; a consumer buying online wants reversibility (cards) so they are protected against a seller who never ships.

10. Messaging standards ISO 20022 and NACHA

Rails are, at bottom, agreements about message formats. Two banks can only settle a payment if they encode it the same way, so every rail defines a standard for how a payment instruction is structured. Two standards dominate the US conversation.

Nacha file formats are the fixed-width record format that ACH runs on. An ACH file is a strict hierarchy of 94-character records: a file header, then one or more batches, each with a batch header, a set of entry detail records (one per payment), optional addenda records carrying extra information, and control records that tally counts and dollar amounts at the batch and file level. Fields sit at fixed positions: the routing number, the account number, the amount in cents, a Standard Entry Class (SEC) code that says what kind of debit or credit it is (PPD for consumer prepaid debits and credits, CCD for corporate, WEB for internet-authorized debits, and so on), and a transaction code that encodes credit versus debit and account type. The format is old and rigid, which is exactly why it is reliable and cheap to process: there is no ambiguity about where a field lives, and the control totals make a malformed file detectable.

ISO 20022 is the modern, global standard and the direction the whole industry is moving. Instead of fixed-width records it uses structured, richly typed XML (and increasingly other encodings) messages with standardized names: a customer credit transfer is a pain.001, a bank-to-bank credit transfer is a pacs.008, a payment return is a pacs.004, a status report is a pacs.002. The advantage over legacy formats is structured, extensible data: far more room for remittance information, clean separation of parties and amounts, consistent identifiers, and the ability to carry the rich detail that compliance, reconciliation, and automation need. Fedwire, CHIPS, RTP, FedNow, and the global SWIFT cross-border network have all moved to ISO 20022, and Fedwire completed its migration to ISO 20022 in 2025. The payoff is interoperability: a payment described in ISO 20022 carries the same well-structured meaning across rails and borders, which reduces the manual repair and reconciliation that ambiguous legacy formats force.

11. Engineering a payment system and ledgering money in flight

Now switch sides from the rails to the system you build on top of them. The defining challenge of a payment system is that a payment is not instantaneous and not always reversible, so at every moment your books must correctly represent money that has left one place but not yet arrived, money in flight, and they must stay correct whether the payment succeeds, fails, returns, or gets stuck.

The foundational technique is to ledger money in flight using intermediate accounts, often called clearing, suspense, or in-transit accounts. You never model a payment as a single instantaneous jump from the payer’s balance to the payee’s. Instead you move the money in stages through holding accounts that represent its true state. When a payout is initiated, you debit the source and credit an in-transit (or settlement) account, recording that the money has left the user but is not yet delivered. When the rail confirms settlement, you debit the in-transit account and credit the destination. If the payment fails or returns, you reverse out of the in-transit account back to the source. At all times the in-transit account holds exactly the float, the money that is genuinely between places, and your ledger never claims money has arrived before it has, nor that it vanished while traveling.

-- A payout modeled as money in flight through an in-transit account.
-- Stage 1: funds leave the user, into in-transit (not yet delivered).
INSERT INTO postings (transaction_id, account_id, direction, amount, currency) VALUES
  (:txn, :user_account,       -1, 10000, 'USD'),   -- credit user (money leaves)
  (:txn, :in_transit_account, +1, 10000, 'USD');   -- debit in-transit (float we hold)

-- Stage 2 (on rail settlement confirmation): in-transit -> destination.
INSERT INTO postings (transaction_id, account_id, direction, amount, currency) VALUES
  (:txn2, :in_transit_account, -1, 10000, 'USD'),  -- credit in-transit (float released)
  (:txn2, :destination_account, +1, 10000, 'USD'); -- debit destination (money arrives)

-- If the rail returns the payment instead, reverse stage 1 back to the user.

This is also where double-entry discipline pays off (the ledger is the source of truth, balances are derived from immutable postings, money is stored as integer minor units, and every transaction’s legs sum to zero). A payment system layers a few extra requirements on top. It must hold an explicit notion of provisional versus final funds, because rails like ACH and cards give you money that can still be pulled back: you may credit a user provisionally while keeping a reserve or a clawback path, and only treat funds as final once the return and dispute windows have closed. It must reconcile against the rail’s own records (the ACH return files, the card settlement files, the wire confirmations), because, as the double-entry track teaches, internally balanced books can still disagree with reality, and only reconciliation against the external settlement record catches a payment the rail saw but your system missed, or vice versa. And it must treat the rail as an unreliable external system whose responses can be delayed, lost, duplicated, or arrive out of order. The in-transit ledger is what lets all of that be true without ever losing track of a cent: every dollar is always in exactly one account, and that account names its real-world state.

12. Idempotency exactly-once and payment state machines

Payments run over networks and external rails, and networks lose messages and retry. The single most important correctness property of a payment system is therefore that submitting the same payment twice does not move money twice. This is idempotency, and in payments it is not optional polish; it is the line between a working system and one that double-charges customers.

The mechanism is an idempotency key: the caller attaches a unique key to a payment request, your system records which keys it has already processed along with the result, and a repeat of the same key returns the original result instead of initiating a new payment. A retry after a timeout (where the caller never learned whether the first attempt succeeded) safely collapses onto the first attempt. The subtle part is that true exactly-once delivery to an external rail is not achievable in the strict sense, because between sending an instruction to the rail and receiving its acknowledgment, anything can fail, and you genuinely may not know whether the rail acted. So practical payment systems aim for exactly-once effect rather than exactly-once delivery: combine idempotency keys (so your own side never duplicates) with at-least-once submission plus the rail’s own duplicate detection and your reconciliation (so a possible duplicate at the rail is caught and resolved). The honest framing is at-least-once attempts made idempotent and reconciled into exactly-once effect.

Around idempotency you need an explicit payment state machine, because a payment is a long-lived process, not a function call. A payment moves through states like initiated, pending (submitted to the rail, awaiting confirmation), settled (the rail confirmed and funds are final), failed (the rail rejected), returned (settled then pulled back), and reversed (you undid it). The transitions are driven by events from the rail, which arrive asynchronously and unreliably. Two things make this hard. First, timeouts: a payment can sit in pending indefinitely if the rail’s confirmation never arrives, so every pending payment needs a timeout that triggers a deterministic resolution (query the rail’s status, reconcile, and either advance or fail it) rather than leaving it stuck forever. Second, out-of-order and duplicate events: a settlement confirmation and a return can race, or arrive twice, so transitions must be idempotent and guarded by the current state, never blindly applied.

stateDiagram-v2
  [*] --> Initiated: request accepted (idempotency key stored)
  Initiated --> Pending: submitted to rail
  Pending --> Settled: rail confirms, funds final
  Pending --> Failed: rail rejects
  Pending --> Pending: timeout -> query status, reconcile
  Settled --> Returned: rail returns / chargeback within window
  Initiated --> Reversed: originator reverses own error
  Settled --> [*]
  Failed --> [*]
  Returned --> [*]
  Reversed --> [*]
  note right of Pending
    Every pending payment needs a timeout
    that resolves it, so none stick forever.
  end note

The design rule that ties it together: model a payment as a state machine whose transitions are idempotent and driven by external events, store an idempotency key so retries never duplicate, and put a timeout on every non-terminal state so a lost rail response becomes a resolvable case rather than a payment frozen forever. Idempotency stops you from moving money too many times; the state machine and timeouts stop money from getting stuck in flight.

13. Failure modes stuck payments duplicates and fraud

A payment system fails in a small number of characteristic ways, and a senior engineer should be able to name each one and the control that catches it. The point is not that failures are avoidable; it is that each has a specific defense, and an undefended one becomes a customer-facing incident or a loss.

Two of these deserve emphasis because they catch teams off guard. The first is the gap between provisional and final funds. On pull rails (ACH debit, cards) the money you receive can be reversed long after you treated the payment as done, so a system that credits users the instant a payment looks successful is exposed to clawbacks it cannot recover if the user has already withdrawn. The mitigations (reserves, holds, only finalizing after the dispute window) are not paranoia; they are pricing the real risk that the rail’s reversibility imposes. The second is fraud on irreversible rails. Wires and instant payments have no chargeback, so the fraud strategy must be preventive rather than corrective: stop the bad payment before it settles, because after settlement there is nothing to claw. This is why instant-rail providers invest heavily in confirmation-of-payee, anomaly detection, and friction on first-time or high-value pushes. The rule across all of these: match your controls to the rail’s reversibility. Reversible rails let you correct after the fact; irreversible rails force you to prevent before the fact.

14. Fundamental principles versus rail-specific conventions

The hardest thing for a newcomer is telling which facts are deep, durable principles and which are conventions of a particular rail or country that could be different elsewhere. Mixing the two leads to systems that hard-code a quirk as if it were a law, or that miss a real invariant because it was buried under acronyms. Here is the separation.

The fundamental principles, true on every rail and likely to stay true, are these. A payment is two jobs (clearing then settlement) separated in time, never one instant event. Final settlement happens in central bank money, because that is the only form with no counterparty to fail. There is an irreducible trade-off among speed, cost, finality, and reversibility, so no single rail wins everything. Push and pull put the risk and the authorization burden on opposite parties, which drives where fraud lands and whether a rail is reversible. Money in flight must be ledgered honestly in intermediate accounts. Idempotency and explicit state machines with timeouts are required because the rails are unreliable external systems. And internally consistent books can still be wrong, so reconciliation against the rail’s records is non-negotiable. These follow from the nature of distributed money movement, not from any one institution.

The rail-specific conventions, which are real and important but contingent, are the rest. The specific rails (ACH, Fedwire, CHIPS, RTP, FedNow) are US institutions; other countries have their own (other RTGS systems, other instant schemes, other batch systems) that fill the same roles with different names and rules. The exact return windows (two banking days, 60 calendar days), the Same Day ACH dollar cap, the chargeback window of roughly 120 days, the specific R-codes, the SEC codes, the interchange percentages, and the message identifiers (pain.001, pacs.008) are conventions set by particular rule-makers and they change over time and across jurisdictions. The four-party card model is dominant but not universal (closed-loop three-party schemes exist). Treat these as configuration and as things to verify against the current rule book, not as eternal truths.

If you carry one separation from this page, carry this: reason from the principles, configure the conventions. The principles tell you what your system must always do (ledger float, enforce idempotency, reconcile against the rail, respect finality). The conventions tell you the numbers and codes to plug in for the specific rail and country you operate in, and they will change, so keep them out of your invariants and in your configuration.

Mastery Questions

1. A marketplace wants to pay its sellers the instant a buyer’s payment clears, and is deciding between paying sellers by ACH credit, by wire, and by an instant rail (RTP or FedNow). Walk through the trade-offs and what you would choose, including how the buyer paid in the first place.

   Answer. Start by separating the two legs, because they have different needs. The buyer-to-marketplace leg usually wants reversibility and buyer protection, which points to cards (a pull rail with chargeback rights) or ACH debit; the buyer is paying for goods and wants recourse if they never arrive. The marketplace-to-seller leg wants the opposite: the seller wants certainty that the money is theirs and will not be clawed back. That argues for a push rail with finality. Between the three options for the payout: ACH credit is cheap but slow (next-day or, with Same Day ACH, same business day) and not 24/7, and it is reversible within windows, so the seller’s money is not instantly final; a wire is final and fast but expensive (often $15 to $35) and business-hours-bound, which is overkill in cost for routine marketplace payouts; an instant rail (RTP or FedNow) is the natural fit: seconds, 24/7, final on receipt, low per-item cost, push-only. I would pay sellers via an instant rail when both banks support it, falling back to Same Day ACH otherwise, and wire only for unusually large payouts where the fee is negligible. The critical caveat ties back to finality: because the buyer leg (card or ACH debit) is reversible for days to months, I should not pay the seller from provisional funds I might have to claw back. So I either hold the payout until the buyer’s funds are sufficiently final, or I take a calculated, reserved risk on the float, but I never treat an instant, irreversible payout as safe to make from money that can still be reversed on the other leg.

2. Your payment service submits a push to an instant rail, the network connection drops before you receive a response, and your system does not know whether the payment went through. Exactly what should happen next, and why is true exactly-once delivery impossible here?

   Answer. True exactly-once delivery is impossible because of the gap between sending the instruction and receiving the acknowledgment: in that window a failure can occur after the rail has acted but before you learned of it, so you genuinely cannot tell from your side alone whether the payment settled. What you do instead is engineer exactly-once effect out of at-least-once attempts. First, the payment must carry an idempotency key that the rail (or your gateway to it) honors, so that resubmitting the same key cannot create a second payment; the safe action is to retry with the same key, which either completes the original or returns its existing result. Second, the payment must be in an explicit pending state with a timeout, so that if retries and status queries still do not yield a clear answer, the timeout drives a deterministic resolution: query the rail’s status endpoint for that idempotency key or payment id, and reconcile against the rail’s settlement records to learn the truth. Critically, because instant rails are irreversible and final on receipt, I must not blindly resubmit without idempotency: a duplicate that settles cannot be clawed back. So the answer is retry idempotently, query status, reconcile against the rail’s record to discover whether the single attempt succeeded, and never let the payment sit in pending forever or get resent in a way that could double-pay.

3. An auditor finds that your internal ledger nets perfectly and every transaction is balanced, yet the total you actually hold at your partner bank is $4,000 less than your ledger says your users collectively own. How is this possible, and how do you find the discrepancy?

   Answer. It is entirely possible, because a balanced ledger proves internal consistency, not agreement with reality, exactly the lesson from double-entry. The books can be perfectly self-consistent while disagreeing with the outside world. Several payment-specific causes produce this gap: ACH debits you credited to users as if final but that were later returned (the return reduced your real bank balance, and if your ledger did not record the return, your books still show the user owning the money); chargebacks pulled back by card issuers that your ledger never posted; a duplicate payout that left your real account twice but was ledgered once; a fee the rail deducted at settlement that you did not record; or a settled payment the rail processed that never produced a posting in your system. None of these breaks the internal balance, because each entry your system did write was valid; the problem is missing or wrong entries relative to what the rail actually did. The way you find it is reconciliation: take the rail’s external records (the ACH return files, the card settlement and chargeback reports, the wire confirmations, the bank statement) and compare them line by line against your ledger, matching on amount, date, and identifier, and surface every item that appears in one and not the other or differs in amount. The trial-balance-style internal check can never find this; only reconciliation against the rail’s own records can, because the truth being checked is not whether your books agree with themselves but whether they agree with what actually settled.