An AP2 mandate is deliberately rail-agnostic. The signed statement of intent, the cart it resolves to, and the non-repudiable trail they leave behind describe what the user authorised, not which network moves the money. That separation lets one authorisation execute over a card network, a bank transfer, an instant credit push, or a wallet balance. But the rail underneath is not an implementation detail: it decides how long the payment takes, what it costs, when the money is truly yours, and whether you get a second chance to fix a mistake. This piece walks the rails an agentic payment can ride and the systems you have to build differently once you pick one.
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.
Availability windows, cutoffs and the banking calendar
Rails are not uniformly available, and an agent that assumes otherwise will produce payments that mysteriously land a day late. Batch rails run on banking days and have submission cutoffs: a file handed over after the cutoff waits for the next window, and weekends and public holidays, which differ between the two ends of a cross-border payment, do not count. Wires have their own, earlier, cutoffs. Instant rails run continuously, but participating banks still take maintenance outages and impose value caps.
The practical requirements are unglamorous and non-negotiable: hold a real calendar per rail and corridor rather than a hardcoded weekday check, compute an expected-completion time from it and surface that to the user, and make submission idempotent so a request racing a cutoff cannot land in two consecutive windows. When a mandate carries a deadline, it is usually the calendar rather than the fee table that eliminates the cheap rail.
Reconciliation is a different problem on every rail
Rail choice quietly rewrites your reconciliation code. Card processing funds you in batches, net of fees: one deposit corresponds to many transactions minus interchange, scheme fees, refunds and chargeback adjustments. Reconciling means matching a batch total against a set of transactions, booking the fee difference separately, and tolerating adjustments that land in later batches than the sale.
Account-to-account rails behave nothing like that. They typically fund gross, per transaction, and the only link back to your order is a remittance reference that has to survive intermediaries intact; truncated, reformatted or user-edited references are the largest single source of unmatched A2A credits. Returns arrive days later as separate debits with their own reason codes, each needing re-association with the original payment and the order. Instant rails are the easiest case: near-real-time confirmation, one credit per payment, no batch to unpick. Several rails means several matching strategies.
Multi-rail fallback without paying twice
Because every rail has an outage, a decline or a cutoff, serious systems keep a fallback chain. Building one safely turns on a detail that is easy to miss: a request that timed out is not a request that failed. A card authorization whose response never arrived may well have succeeded at the issuer, so falling straight through to a second rail risks charging the user twice. Resolve the first attempt to a definite state, by idempotency key, query API, or worst case reconciliation, before initiating any alternative.
The second rule follows from finality: irrevocable rails go last in the chain, never first. If an instant push succeeds and you then discover the earlier card attempt also went through, you cannot unwind the instant leg to correct the duplicate; in the other order, you can. And a fallback is a change of execution, not of authorisation. If the substitute rail alters what the user agreed to, through a materially different fee, a different currency, or the loss of dispute rights they relied on, re-confirm the mandate rather than quietly rerouting it.