Multi-Rail Agent Payment Routing: One Wallet, Every Rail

Every new agent payment rail solves a problem and creates one. x402 made USDC pay-per-call work on Base. MPP brought multi-rail and fiat through Stripe and Tempo. Circle Gateway batched stablecoin settlement. Each is genuinely useful. Together, they're a tax — because the agent that wants to pay any merchant now has to speak all of them.

This is the case for multi-rail agent payment routing: instead of teaching your agent every protocol, you put a neutral router in front of all of them. The agent funds one wallet and signs one shape; the router translates that into whatever each merchant speaks. As the rails fragment, this approach gets more valuable, not less — which is the opposite of betting on any single rail.

The integration tax is real and it compounds

Standardization happened at the challenge layer — HTTP 402 — but not below it. Underneath the "you must pay" response, every rail diverges:

• x402 settles USDC on-chain (Base, Solana), with its own signing flow.
• MPP settles tempo-native and spans stablecoins, cards, and fiat, with its own auth scheme.
• Circle Gateway batches stablecoin settlement for merchants on Circle's network.
• And the next ones — ACP, UCP, AP2, A2A — each add another credential set, another chain, another reconciliation path.

Support one rail and your agent stalls on every merchant using another. Support them all by hand and you've signed up to maintain a growing matrix of keys, chains, liquidity pools, and settlement logic — work that has nothing to do with what your skill actually does. Worse, the tax compounds: each new rail multiplies the integration surface instead of adding to it linearly.

That's the trap of picking a rail. You're not choosing a payment method; you're making a bet that the market will consolidate around your choice. So far it's doing the opposite.

What rail-neutral routing means

Rail-neutral routing inverts the model. Rather than the agent adapting to each rail, a router adapts the rails to the agent.

With SELAT, the agent does two simple things:

1. Funds one wallet — a single Arc-funded wallet, not one per merchant or chain.
2. Signs one shape — the same payment signature every time, regardless of what the upstream wants.

The SELAT Router does the hard part. It takes that one inbound payment and translates it into the scheme the merchant speaks:

• Direct — when the merchant is Gateway-batched on a chain the payer already supports, SELAT settles directly and skips the router entirely.
• Routed — for erc-3009 or tempo-native upstreams, the request goes through the Router, which verifies the inbound payment and translates rails on the outbound leg, so the agent only ever signs one shape.

The four capabilities this maps to — runtime access, federated discovery, credential translation, settlement orchestration — are precisely the four jobs you'd otherwise hand-build per rail.

What it looks like in practice

[selat-pay] probing upstream directly to detect scheme
[selat-pay] mode=routed (upstream not Gateway-batched on eip155:8453; using router)
[selat-pay] quoteId=911f6e4b-8919-4536-bd48-fe5cbeded3ac
[selat-pay] price=$0.031500 on eip155:8453
[selat-pay] signed; submitting paid request
[selat-pay] status=200

The agent expressed an intent. SELAT discovered a service, detected the rail, chose direct vs. routed without any branching in your code, paid, and returned a 200. Add a new rail next quarter and nothing in your agent changes — the router absorbs it.

Why neutrality is structural, not a feature

There's a reason most payment players can't offer this credibly: they own a rail. A wallet or a chain wants to be the destination — its business depends on routing volume to itself. A genuinely neutral router has no such incentive. It surfaces every payment option on a merchant and lets the payer decide; ranking stays about what the service does, not how it gets paid.

That's the "Switzerland for agent payments" position — and it's defensible precisely because a rail owner can't copy it without cannibalizing its own rail. Neutrality is the one thing in this market whose value rises as the landscape fragments.

It also unlocks the thing no single rail can offer: cross-rail composition — a skill chaining paid endpoints across x402 and MPP in one run, each merchant paid directly on its own rail, every call drawing on one self-custody balance and landing in one ledger. Once that's normal, the interesting unit stops being the payment and becomes the settled skill. That, more than any single transaction, is what a rail-neutral router is for.

When you need it (and when you don't)

• You probably don't if your agent only ever talks to one merchant on one rail you control. Use that rail directly.
• You probably do the moment your agent needs to pay merchants you don't control — because then they pick the rail, not you — or the moment you'd rather ship your skill than maintain a payments matrix.

Most builders cross that line faster than they expect. The first time a skill needs a second merchant on a second rail, the routing question stops being theoretical.

For the mechanics, see how the SELAT Router resolves a payment end to end, or if you're still weighing protocols, start with x402 vs MPP.