Card rails: authorization, capture, clearing, settlement
The card networks are the most familiar rail and the most misunderstood, because a single card payment is really four distinct events spread over days. Authorization is a real-time request through the acquirer and network to the issuer, which checks the account and places a hold; it returns in well under a second and moves no money. Capture is the merchant declaring what it intends to take, often hours or days later when goods ship. Clearing is the batched exchange of those captures, and settlement is the funds movement that follows.
For an AP2 implementation this matters because the mandate is satisfied at authorization, but the money is not. An agent that treats an approval code as money in hand will misreport balances, over-commit budgets and double-book inventory. The correct model is a state machine (authorised, captured, cleared, settled, possibly reversed) where each state carries a different level of certainty and permits a different set of actions.
Interchange and the real price of chargeback rights
Cards are the expensive rail, and it is worth being precise about why. A merchant pays a merchant discount rate assembled from interchange (which flows to the issuer), scheme fees (to the network), and the acquirer markup. Interchange is not one number: it varies by card type, by card-present versus card-not-present, by merchant category and by region, and several jurisdictions cap it by regulation. A single headline percentage will mislead any rail-selection model built on it.
What that price buys is a dispute system. Cardholders can dispute a transaction, the issuer can raise a chargeback, and the merchant can defend it through representment. Crucially, this exists because network rules and consumer protection regulation created it, not because the message flow is technically undoable. Reversibility on cards is a designed right, and you rent it.
Account-to-account rails: batch debits versus instant credit pushes
Bank rails split along an axis that matters more than speed: is the payment pulled by the payee or pushed by the payer? A batch debit rail such as ACH or SEPA Direct Debit lets a merchant holding a mandate pull from the payer's account. Because someone else's account is being reached into, these rails carry return rights: unauthorised consumer ACH debits can be returned within a long window, corporate entries within a much shorter one, and SEPA Direct Debit grants consumers an eight-week no-questions-asked refund right, far longer for unauthorised collections.
Credit transfers behave in the opposite way. An ACH credit or SEPA Credit Transfer, once sent, cannot be unilaterally undone by the originator; the best available action is to request a return, which the receiving bank is under no obligation to grant. Instant rails such as RTP, FedNow and SEPA Instant are credit-push only, run continuously rather than on banking days, and settle in seconds with finality. Same rail family, opposite dispute posture, purely because of direction.
Stored value and wallet balances
The third option is not a network at all. When both sides of a transfer are accounts on the same ledger (a wallet balance, a platform account, a closed-loop stored-value product) moving value is a pair of ledger entries, not a rail hop. It is instant, essentially free at the margin, always available, and it never fails halfway: there is no external party to time out.
The catch is that a closed loop has to be filled and drained. Funding and paying out both happen over a real rail, so the wallet does not remove rail risk; it relocates it out of the moment of purchase and into a top-up flow whose timing you control. That is valuable for agentic payments: a pre-funded balance turns an uncertain multi-second external call into a deterministic local write. But holding customer money is a regulated activity, and safeguarding obligations, segregation of funds and e-money or money-transmission licensing follow the balance, and belong in the design from day one.
Finality moves the dispute burden upstream
Here is the engineering consequence that dominates everything else. On a reversible rail a mistake is a cost: you refund, you eat a chargeback fee, you argue representment, you move on. Controls can be partly retrospective because a mechanism exists for undoing the outcome. On an irrevocable rail there is none. Once an instant credit push settles the money is gone, and every control you would have applied afterwards has to be applied before submission or not at all.
That single fact reshapes the system. Mandate verification must be strict and synchronous rather than eventually consistent. Confirmation-of-payee name and account matching becomes mandatory rather than a nicety. Velocity and value limits, first-time-payee cool-offs, anomaly scoring and step-up confirmation all move from a monitoring queue into the blocking path. Authorised push payment fraud, where a legitimate user is tricked into authorising a real transfer, is the canonical failure, and no after-the-fact control reaches it.
Rail selection as a policy function, not a preference
Rail selection should therefore be a deterministic function over the mandate and its context, evaluated and logged like any other authorisation decision. The inputs that carry weight are: the amount, because fixed-fee and percentage-fee rails cross over at a predictable point; the corridor and currency, which decide what is reachable at all; what the payee accepts; the certainty a deadline requires; and how much reversibility is needed.
That last input deserves to be explicit. A payment to a first-time counterparty for a good delivered later wants a reversible rail, and paying card fees for it is buying insurance, not wasting money. A recurring transfer to a known, verified payee is where an instant rail's cost advantage is real. Encode the preference order in policy, record which rail was chosen and why alongside the mandate, and treat a user's stated preference as an input the policy may honour, not an override.
Cost, latency and reversibility side by side
The shape of the trade-off is stable even though the numbers are not. Fees, windows and cutoffs vary by country, scheme and contract, so the table below is directional: take real figures from your own processor agreements.
| Rail | Fee shape | Time to certainty | Reversible? |
|---|---|---|---|
| Card | Percentage plus fixed | Auth in ms, funds in days | Yes, by scheme rules |
| Batch debit (ACH, SEPA DD) | Low flat | Days | Yes, within return windows |
| Batch credit transfer | Low flat | Days | Only by request |
| Instant credit push | Low flat | Seconds | No |
| Wire | High flat | Same day | Effectively no |
| Wallet balance | Near zero | Immediate | Yes, internal ledger |
| Stablecoin / crypto | Network fee | Minutes | No |
Stablecoin mechanics and cross-currency legs have their own dedicated articles. Note the pattern the table exposes: the cheapest and fastest rails are systematically the least reversible. That correlation is the whole design problem, not a coincidence.