Rails

x402

Pay for a web request as you make it. The natural shape for anything sold by the call.

mpp

The same request-and-pay shape, not tied to one way of settling underneath.

l402

Lightning, over the same web request. Suited to amounts too small for a fixed fee.

onchain

Straight to the chain, where finality is the point.

card

Through your own processor. We never hold the card details.

ap2

Paying under an authority a person delegated in the Agent Payments Protocol format.

acp

Checkout through the prescriptive commerce standard.

ucp

Checkout through the capability-based one.

ach

The batch bank rail. Deferred finality, reversible, and the way most suppliers are actually paid.

wire

The real-time gross settlement bank rail. One message, final on receipt, and nothing comes back.

Backends underneath a rail

A rail is how value moves. Who executes it is a separate choice, and several providers sit underneath one rail rather than beside it.

ATXP

A hosted payment server with a custodial wallet and a tool store. Paid tool calls settle over x402 in stablecoins, so it is a selectable backend under that rail and not a rail of its own. We hold the payer side: the resource answers with a challenge, we sign the transfer authorisation locally with our own key, and the retry carries it.

Card processors

Your own acquirer or gateway behind the card rail, through one adapter interface: authorize, capture, refund, reverse.

Lightning nodes

The node stays yours behind an injected seam. We bind the wire format, not a wallet.

The two bank rails

The agentic-payments landscape is almost entirely card and chain, and both are consumer-shaped: small, close to instant, and reversible on a clock measured in minutes or in months of dispute process. The business-to-business half of the same economy runs on ACH and wire, which are neither.

ach

A batch rail. A file is cut at a cutoff, exchanged overnight or in one of three same-day windows, and posted the next banking morning. Funds are deferred and can be pulled back after settlement by the receiving bank, without the originator agreeing.

wire

A real-time gross settlement rail. One message, one settlement, final on receipt. There is no return window and no unilateral pull-back. A recall is a request the beneficiary's bank may refuse, which is a negotiation, not a reversal.

Finality and reversibility come apart from speed here. Wire is fast and irreversible. ACH is slow and reversible. Both fields are stated rather than inferred from the other, because inferring would be inferring the expensive half. An instruction whose terms claim otherwise is refused rather than settled under terms the rail cannot honour.

Cutoffs and banking days

The single thing the two rails share, and the reason they are one model, is a cutoff. Money moves in batches, not in requests. A payment submitted at 16:05 on the Friday before a Monday holiday moves on Tuesday, and an agent that does not know this promises Friday.

The bank's day is a fixed offset from UTC supplied by the operator, not a time-zone identifier. A zone identifier resolves against a database that ships updates, so the same inputs could produce two different answers on two machines a year apart, and that is the one property a replayable forecast may not have. An operator whose bank observes summer time supplies the offset in force and re-supplies it when it changes, which is a visible decision rather than an invisible library upgrade.

A forecast is a pure function of the timing parameters, the amount and the instant. It reports the track taken, the release date, the date funds are expected to be available, whether the request fell after cutoff, and how long the money stays recallable. Every rounding goes the slow way: where a boundary is ambiguous the later instant is taken, and where a faster track cannot be proved available the standard one is used. A forecast that is late is a disappointed supplier; a forecast that is early is a broken promise, and those are not the same cost.

Value changes almost nothing. A forty dollar ACH credit and a four hundred thousand dollar one submitted at the same minute settle on the same morning. The one exception is the same-day track, which exists only below a per-transfer ceiling, and it is a cliff rather than a curve: one minor unit above the ceiling the transfer does not slow down slightly, it settles on a different day.

A wire after cutoff is refused, not queued

A wire submitted after cutoff does not move until the next banking day. Its instruction nonetheless claims instant finality, and there is no honest receipt for that: the agent would be telling a supplier they have been paid when the message has not left. So it is refused. That is structural and has no opt-out.

The same reasoning applies one step later. On ACH a receipt may be minted once the instruction is accepted, because ACH terms say deferred and reversible, and that is an honest record of a payment that is on its way and can still come back. On wire it may not: a receipt over an instruction still sitting in a queue would assert a finality that does not exist yet.

Return windows

An ACH return is not a refund and not a chargeback. It is the receiving bank taking money back unilaterally by transmitting a code in a file. The originator is told; the originator does not agree. The window is a function of that code, not of the transfer, and the two classes run on two different clocks.

Administrative and funding

The account was closed, the number was wrong, there was no money there. These arrive within a small number of banking days from settlement.

Unauthorised

The account holder disputes it. This runs on calendar days from settlement, and the deadline commonly quoted is sixty of them, because it runs from the account holder's statement rather than from the file.

The two units are kept apart deliberately. Collapsing them into one would be wrong by a weekend in one direction and by a fortnight in the other. There are roughly eighty return codes and fourteen are enumerated. A code outside that set fails closed onto the longest window, because the cost of the two mistakes is not symmetric: treating a long window as short tells an agent that money is safe when it can still be taken, and treating a short window as long only costs patience.

A late return is reported, not rejected. Whether a return arrived inside the window its code was entitled to is stated, and nothing pretends the money can be refused: it has already gone. An untimely return is evidence for a dishonour claim, which is a claim somebody makes with the assessment in hand.

Stopping a bank transfer

The cancellation window closes at release, not at settlement. Once the file is cut or the wire message is sent there is nothing to cancel on either rail: on ACH the instruction is in an interbank file, and on wire the money is already the beneficiary's. Everything after release is a reversal request, which is a different thing with a different success rate, and a cancellation attempted after the window is refused without asking the bank rather than presented as one.

There is no capture beat and no reverse beat. A bank transfer has no hold to capture, and reverse would be a lie on both rails.

Choosing one

You state the rail in the terms of the instruction. It is not a hint: the rail is one of the fields the decision reasons over, because paying the same amount over a card and over a chain are different commitments.

terms: {
  rail:          "x402",
  reversibility: "irreversible",
  finality:      "instant",
  credential:    "http-sig",
  capitalSource: "payer",
  presence:      "delegated",
}

More than one at once

Where a job needs several payments that must all land or none, the platform reads the backing system's declared ability to settle a batch atomically before anything moves, rather than discovering halfway through that it cannot. Where atomicity is not available and a call has already landed, that is recorded positionally rather than silently unwound, because pretending an onchain effect did not happen is not something software gets to decide.

Buying, rather than paying

Commerce sits above payment. Agreeing what is being bought and for how much runs through the commerce standards, and the payment underneath it still resolves to one of the rails above. The decision happens in the same place either way.