Coinbase x402 vs Google A2A: Two Opposite Payment Orderings for Agent-to-Agent Payments

A developer building a research agent that farms work to three others (search, summarizer, translator) needed sub-cent machine-to-machine payments. Stripe's $0.30 minimum on a $0.001 call is 300x overhead; on-chain L1 gas is similar; subscriptions require human pre-negotiation. They found x402, Coinbase's implementation of HTTP 402 "Payment Required" — a stateless facilitator for sub-cent payments on Base, settling in ~2s for ~$0.0001 via EIP-3009 pre-signed auths passed as headers.

The core question: payment ordering

When you have verify (fast, off-chain), settle (slow, on-chain), and actual work (LLM call), three orders are possible:

• A: verify → run → settle
• B: verify → settle → run
• C: verify → reserve → run → capture (credit-card hold pattern — not possible with EIP-3009's one-shot design)

Coinbase's middleware uses A; Google's A2A x402 extension uses B. The difference hinges on work duration: Coinbase's caller is a fast API endpoint (sub-500ms), so the verify-settle gap is negligible. For an agent calling other agents, the window stretches to seconds or minutes — long enough for the payer to drain their wallet after verify but before settle, gifting free compute.

Settle-first wins for agentic workloads

The developer chose B (verify → settle → run) because agent work costs real money ($0.30+ per call) and is slow. With settle-first, a failed payment never runs the LLM. They stress-tested four scenarios:

• Valid signature, wallet drained before settle lands → settle reverts, no compute wasted ($0 loss).
• Two parallel requests from same wallet with different nonces, same balance → one settle succeeds, the other fails chain race, never reaches model.
• Replayed payment header → caught at nonce check before verify, returns 402.
• Facilitator timeout at 10s but chain confirms at 25s → orphan payment (payer debited, task failed). This is a chain-under-load property, not fixable by ordering.

A failure mode of settle-first: payment lands, but work fails (500 error, bug). The provider handles it with persisted nonce/auth metadata and manual refunds.

The full flow is open source with e2e tests running all four scenarios on a laptop. github.com/GetBindu/Bindu