We Gave Our API a Cash Register. Then We Asked an AI to Rob It — x402 Gateway on Arc

Why would a machine need a cash register?

Because every other way of charging for an API assumes a human. Stripe checkout assumes a person with a card and a browser. API keys assume someone who registered an account first. An autonomous agent has none of that — it has a wallet. x402 is the pattern where HTTP status 402 Payment Required becomes real: the server answers a request not with a login page but with a price tag, and the client retries the same request carrying a cryptographic payment proof.

For a junior: think of a vending machine instead of a supermarket. No account, no cart, no checkout wizard. You walk up with exact change, the machine prices the item, takes the coin, and gives you the thing plus a receipt — all in one interaction. Our gateway is that vending machine for HTTP resources, built on the payment rails from the previous episodes.

How does the 402 loop work?

In four layers, bottom to top. Everything the client sees is derived server-side — the price, the network, the recipient — so a client can never say "I paid" for a resource that wasn't charged.

Domain types live in the payments package; transport lives in the server; settlement stays in the existing seam.

1. Registry — a PaidResource declares id, method, path, priceUsd, network. Unregistered routes pass the gate untouched, so the gateway is strictly opt-in per route.
2. Price resolution — a catalog-first PriceResolver, falling back to the registry's declared price. Resolved USD is converted to USDC atomic units at the boundary.
3. Service facade — builds the payment requirements, delegates verify+settle to the existing x402 seam (the same one the legacy routes use — we didn't reimplement settlement), appends a UsageRecord, and resolves agentId from the payer's wallet binding — or null when unbound.
4. Middleware — the Hono gate. No PAYMENT-SIGNATURE header → spec-compliant 402 + PAYMENT-REQUIRED. Signature present → settle → record usage → PAYMENT-RESPONSE receipt header → serve the resource.

One round trip for the price tag, one for the goods. The receipt travels in the response header.

What did the adversarial audit break?

After the pilots shipped — 30 unit tests + 8 end-to-end tests, all green — we ran an Arc Studio adversarial review. Verdict: REQUEST CHANGES — 1 Critical, 6 High, 9 Medium. The green tests had covered the happy path and the "payment rejected" path. The audit covered the third path: payment accepted, then something else breaks.

• C-1 — paid but nothing received. Settlement succeeded on-chain, then a database hiccup in the usage-record write threw a bare 500. The payer's nonce was already spent, so a retry could never recover — no resource, no record, no receipt. Now: post-settle accounting is wrapped so a paid request always serves the resource and emits PAYMENT-RESPONSE; failures are logged as reconciliation records instead.
• H-1 — the free HEAD request. Hono answers HEAD through the GET handler, but our route lookup matched methods exactly — HEAD /api/v1/fx/delta/premium skipped the gate entirely. Now HEAD is normalized to GET before lookup.
• H-2 — client-controlled dedupe key. x-request-id anchored usage dedupe; a client could reuse it across different payments and silently suppress records. The anchor is now the settlement tx — cryptographically unique per payment.
• H-3 — charge first, fail later. Settlement ran before the handler even existed in memory; a dead downstream engine meant a paid 503. A preCheck now refuses unbootable requests before the 402 challenge — you can't be charged for what can't be served.
• H-5 — wrong attribution. The usage record wrote the registry's declared network instead of what actually settled. Now it records settle.sourceChain, and the advertised accepts are filtered to the resource's own network.
• H-6 — a mount that leaked. app.route("/api/v1", passportRoutes) exposed every future passport route under the paid prefix. The pilot now mounts the single handler explicitly.

The audit found the gap between "payment succeeded" and "resource served" — the seam every money path is made of.

What's live and how do I try it?

Behind X402_GATEWAY_ENABLED on Arc testnet — Arc USDC only in v1:

• POST https://agentbadge.xyz/api/v1/passport/request — $0.10, issues an agent passport (same handler as the legacy route)
• GET https://agentbadge.xyz/api/v1/fx/delta/premium — $0.02, premium FX-delta snapshot + payment: {txHash, network, amount, receiptId} in the body

The two pilot slots: same handlers as the legacy rails, now reachable by a machine carrying coins.

Registering a new paid resource is a registry entry, not a new code path: { id, method, path, priceUsd, network }. The middleware, challenge, settlement, usage record and receipt come free.

What are the honest limits?

• Pilots, not production. Two routes, flag-gated, Arc testnet. The legacy passport rail and the Celo FX gate are untouched on purpose — migration is additive, never a silent swap.
• No live numbers yet. End-to-end is proven with the seam stubbed at the boundary (8 e2e tests). Real testnet txs through the gateway haven't run at press time — we say so rather than quote a receipt count we don't have.
• Bearer payments. A valid signature pays; it isn't bound to a specific resource by the wire protocol. That's x402's design, and the mitigation lives in the requirements the server derives, not in the client's wallet.
• One audit. Adversarial review we fixed and re-verified, not a formal verification. The regression tests — HEAD gating, zero-price, post-settle crash, engine-off refusal — are the artifact that outlives this article.

The deeper principle is the same one the reconciliation episode ended on: a chain payment isn't an event you receive, it's a claim you verify — and this episode adds the other half: once verified, everything after the money moves is customer service, and it must never cancel the sale.