peage Shapes the x402 Fiat Binding — A Production Rail Joins the Spec

In July 2026, the x402 foundation opened PR #2612: a credit network binding for batch-settlement, designed for general API monetisation with no on-chain capital requirement. Pre-purchased fiat credit bundles, short-TTL attestations, atomic decrement-on-authorize, PSP-agnostic settlement. The shape of a payment rail that doesn't need a blockchain.

I'd already built one. peage is a fiat pay-per-call rail for agents: prepaid wallets funded by card via Stripe Checkout (EUR, cents as the atomic unit), merchants settle with one HTTP call, every settlement returns an HMAC-signed receipt that anyone can verify without auth. Live since July 2026, speaking the x402 v2 wire format on network peage:eur.

When the spec is being drafted and you're already running the thing it describes, you have something most participants don't: production data. So I shared it.

The comment that moved the spec

My first comment on the PR covered five concrete points from peage's production experience:

• Credit-backed commitment works. Prepaid balance, atomic decrement on settle, no chain involved. The receipt ID maps to the spec's transaction field.
• Both fixed and variable pricing map. peage ships synchronous exact-amount settlement and a hold→capture escrow (reserve max, settle actual, remainder auto-refunds on TTL) — i.e. exact and upto semantics on a fiat credit rail.
• Idempotency must be normative. Upstream retry semantics were unspecified. peage requires merchant-supplied idempotency keys so a retried settle can never double-bill. I argued the fiat-credit binding should make this normative, not optional.
• Caller-side spend caps (per-charge + per-merchant daily, enforced by the wallet, not the merchant) turned out to be the thing that makes operators comfortable handing a token to unknown merchants.
• Auditability: peage exposes a public solvency endpoint recomputing the ledger invariant per request — funded == float + escrow + merchant balances + fees. For credit-backed bindings where a trusted intermediary holds balances, this is table stakes.

What the revision did

The PR author, @orgtom78, pushed a revision on July 25 that folded in the feedback:

• Idempotency is now normative on both /authorize (coalesce concurrent redemptions) and /settle (jti, concurrency-safe). Exactly what I'd argued for.
• /settle uses the standard SettleRequest with the actual charge in settlement-time paymentRequirements.amount, dropping non-standard top-level fields.
• aud + resource attestation claims are now REQUIRED, closing cross-audience and cross-resource replay.

Another contributor, @sunsetpatrol (Stipendex), agreed on the idempotency point and shared three layers of protection that turned out necessary in practice — in-flight coalescing, persistent dedup, and retry-safe settlement. The thread became a real design conversation between people running production rails, not just spec authors.

The alignment check

I posted a second comment checking peage's live implementation against the revised spec. The result: most of it already maps cleanly.

• Standard SettleRequest — peage already carries the actual charge in paymentRequirements.amount. No changes needed.
• Idempotency via jti — peage has had idempotency_key with INSERT OR IGNORE since launch. Same semantics, different name. We'll alias.
• exact scheme on a named network — peage speaks scheme: "exact", network: "peage:eur", asset: "EUR". Already live and tested.

The /authorize attestation flow is new — peage doesn't have a pre-spend authorization round trip. For a synchronous fiat rail where balance is checked at settle time, the extra call doesn't buy much. But for high-throughput merchants who want to reject unfunded callers before doing work, it matters. We'd implement it as a thin wrapper over our existing /x402/verify (which already checks balance + caps without moving money).

One concrete data point on the holdExp settlement window: peage's hold→capture escrow defaults to 900s (15 min), not the spec's recommended 24h. For synchronous per-call settlement, shorter is better — it bounds the time funds are locked. The window should be scheme-specific, not a flat minimum.

Spend caps: the payer side matters more than the resource side

I also commented on issue #2405, which proposes a fiscal_authority metadata block for agent spend governance. The proposal puts spend caps in resource metadata — the merchant declares what it charges.

In practice, the cap that matters for agent safety is the payer-side cap. A resource can say "I charge 2 cents per call" but that doesn't tell the operator whether their agent could accidentally spend €50 in a tight loop. peage's max_charge_cents + daily_cap_cents — set by the wallet owner, enforced by the rail on every charge — does.

The resource declares its price. The payer declares its cap. The rail enforces both. That's the separation that's worked in production.

What this means for peage

peage is now an explicit interop test target for the x402 fiat binding. When the spec stabilizes, we'll run the conformance test vectors against our /x402/verify and /x402/settle endpoints. Our test suite already covers the v2 header flow end-to-end — PAYMENT-REQUIRED, PAYMENT-SIGNATURE, PAYMENT-RESPONSE, unsupported_scheme rejection, invalid_network rejection, v1-tolerant payloads.

The peage MCP server is also published in the official MCP registry (fr.intrane/peage-mcp), so any agent using Claude Code, Cursor, or any MCP-capable client can discover peage, mint a wallet, and pay for API calls — all through the standard tool discovery flow.

Why this matters

The x402 protocol started as a Coinbase project for crypto-native API payments. In April 2026 it was contributed to the Linux Foundation with 40+ members including Visa, Mastercard, Stripe, Google, and AWS. The credit-backed binding in PR #2612 is the path that makes x402 work for fiat — for the 99% of API providers who will never touch a blockchain.

peage is proof that the shape works. Not a whitepaper, not a demo — a running rail with signed receipts, public solvency proofs, caller-enforced spend caps, and a live MCP registry entry. When the spec authors needed production data to validate their design, peage had it.

That's the value of building first and speculating second. The spec is better because someone had already shipped it.

Try it: read the agent docs · source code · MCP server · live solvency proof