Adding a Mock ACH Rail: US Payouts by Routing Number
ACH is the workhorse of US payments — payroll, bills, and most account-to-account transfers ride it. It is also slow, batch-based, and unforgiving of a wrong routing number. To build against it safely, you want a mock rail that behaves like ACH without moving real money. KibiPay ships exactly that: a sandbox ACH rail addressed by ABA routing number and account.
What ACH addressing looks like
A US bank destination is two numbers: a nine-digit ABA routing number that identifies the bank, and an account number that identifies the account within it. The routing number has a built-in checksum, so a single mistyped digit can be caught before submission. Modeling both fields — and validating the routing checksum — is the first job of the mock rail.
- ABA routing number: nine digits, checksum-validated.
- Account number: variable length, bank-specific.
- Transaction type: credit (payout) or debit (pull).
Batching, not instant
Unlike instant rails, ACH settles in batches on a schedule. A real integration submits files that clear over hours or days. A faithful mock preserves that shape: the payment does not resolve the instant you submit it; it moves through pending states and then settles. Building against that timing early saves you from designing a UI that assumes instant confirmation and then breaking when it meets real ACH.
| Stage | Meaning |
|---|---|
| Submitted | Instruction accepted into a batch |
| Processing | Batch sent, awaiting settlement window |
| Settled | Funds credited to the destination |
| Returned | Rejected — bad account, insufficient funds |
Why a mock rail earns its place
You cannot iterate quickly against a system where every test costs real dollars and takes a day to clear. A mock rail gives you deterministic, instant feedback while preserving the semantics that matter: routing validation, batch timing, and return codes. You can force a return to test your failure handling, something impossible to schedule against the real network.
Fitting ACH into a multi-rail world
In KibiPay, ACH is one destination type behind an alias. When a directory entry has a US bank account, ACH becomes a candidate rail the routing engine can choose — typically for larger, non-urgent payouts where its low cost wins over its slow speed. The sender never types a routing number; they pay an alias and the engine reaches for ACH when it is the right tool.
Returns are part of the design
ACH returns are a fact of life: closed accounts, wrong numbers, insufficient funds. A payout system that ignores returns will silently lose money and trust. The mock rail lets you exercise return handling deliberately, so your reconciliation and retry logic are proven before real funds are ever at stake.
Where to go from here
ACH is a good lens on how differently rails address accounts. To compare its routing-and-account model against sort codes and wallet strings, read our breakdown of payment addressing, and for the general concept of a rail see what is a payment rail.
Reconciliation from day one
The hardest part of ACH is not sending — it is knowing, later, exactly what happened to each payment. Because settlement and returns arrive asynchronously, you need a reconciliation model that matches every submitted instruction to its eventual outcome, including returns that land days after the fact. Building this against a mock rail means you can generate returns on demand and prove your matching logic before real dollars are ever in flight. A payout system without solid reconciliation slowly loses track of money, and lost track of money is lost trust. The mock rail's real gift is that it lets you rehearse the unhappy paths — returns, reversals, and delays — as thoroughly as the happy one, so nothing about production timing catches you by surprise.
A mock ACH rail is not a toy — it is the safety harness that lets you build real US payouts with confidence before you flip to production.