Machine Payments for AI Agents: A Custom USDC Gateway on Base

Correction — 19 October 2026: This is a custom USDC transaction-proof gateway, not a conformant standard x402 v2 implementation. Its exact-transfer challenge and raw transaction-hash PAYMENT-SIGNATURE are not compatible with stock x402 SDK payment payloads. No production paid-to-download test has been verified in this review; delivery preflight improvements are still in a draft PR. A reachable endpoint or successful challenge does not establish payment or fulfilment readiness. Buyers must authorize any wallet spending; do not send funds based on this article.

Disclosure: I work on Datanest Stores. This correction was prepared with AI assistance and checked against the current source audit.

Datanest Stores has a custom self-custody USDC payment gateway on Base, implemented on a Cloudflare Worker that reads the chain rather than signing transfers. It sits beside our MCP discovery and buyer-authorized Stripe Checkout flow. This article describes the gateway implementation; it is not evidence of a completed production payment and download.

This post walks the intended challenge → pay → verify → deliver flow and its implementation choices: per-order recipient addresses derived from a public key, exact-amount transfer checks, an optional second-RPC cross-check, and error handling. These controls need deployment configuration and end-to-end verification before a buyer should rely on them.

The flow: challenge → pay → verify → deliver

The route uses HTTP 402 Payment Required, but those status codes and header names alone do not establish x402 interoperability. Datanest's custom gateway lives at GET /api/x402/products/{id} on the agent-MCP Worker. A custom client must understand the order id, exact transfer, and transaction-hash proof described below; standard x402 v2 clients cannot be assumed to work.

1. Challenge. The agent requests a product with no proof. The Worker mints a 128-bit secret order id, derives a per-order recipient address, computes the exact price, and durably writes the order — if that write fails, it returns 503 rather than handing out a challenge whose record isn't durable. The response is a 402 with a base64 PAYMENT-REQUIRED header describing the accepted payment (scheme exact-transfer, network eip155:8453, the USDC asset, the exact amount, and the derived payTo address), plus the secret order id in an X402-Order-Id header. The order expires after X402_ORDER_TTL_SECONDS (default 900 seconds).

2. Pay. The agent transfers exactly the price in USDC to that order's payTo address. The implementation checks the order-specific recipient, token, network, amount, expiry, and transaction proof. The buyer must explicitly authorize the transfer and separately account for network fees; an HTTP challenge does not authorize spending.

3. Verify. The agent retries the same URL, now carrying PAYMENT-SIGNATURE: <tx-hash> and X402-Order-Id. The Worker fetches the receipt, requires a successful transaction (status === 0x1) at valid block heights with at least X402_MIN_CONFIRMATIONS confirmations (default 5), and decodes a strict 3-topic + 1-word ERC-20 Transfer event to the order's address for exactly the price — exact ===, never >=.

4. Deliver (intended behavior). After successful verification the implementation marks the order paid, records the payer address, and attempts to stream the product ZIP from R2 with a PAYMENT-RESPONSE header. Paid-order retries are intended to support repeat downloads. This is an implementation description, not a verified production delivery guarantee; product availability, storage bindings, RPC configuration, and the entire paid-to-download path still require validation.

Why the tricky parts matter

The unglamorous part of machine payments is replay protection. A tx hash is public, so it is never trusted alone: delivery requires both the secret order id (only ever handed to the payer, never written on-chain) and a transfer to that order's own derived address.

The derived address is a non-hardened child of the merchant master public key:

tweak     = keccak256("x402-order-v1" ‖ orderId ‖ productId ‖ network) mod n
child_pub = master_pub + tweak·G
address   = last 20 bytes of keccak256(uncompressed child_pub)

Seeding the tweak with the 128-bit order id is intended to bind a transfer to one order rather than reuse a public transaction hash across orders. This is a design goal, not a security proof or an audit guarantee. This replaced an earlier amount-binding scheme (price + 4-digit nonce) that had only 10⁴ entropy and was forceable via a few thousand free challenges. The merchant sweeps a child offline with child_sk = (master_sk + tweak) mod n, so recovery requires the matching merchant private key and the correct derivation data — without the Worker ever holding a signing key. It holds only the master public key and address; the private key lives offline and is used solely to sweep the master and derived addresses.

Verification also distrusts a single RPC provider. If X402_RPC_URL_VERIFY is configured, the Worker re-fetches the receipt from a second independent provider and requires agreement on status, block, and the decoded transfer — disagreement fails closed. The fail-closed list also covers a missing or invalid X402_MASTER_PUB (the custom gateway rejects challenges without valid binding configuration), an invalid cross-check URL, and any order-write failure. The default verification path additionally retries its primary RPC twice and fails over across a list of public endpoints.

Two smaller details worth stealing: optional payer binding — if the agent declared an X402-Payer header at challenge time, the verified transfer's from must match it or delivery is rejected with a payer_mismatch; and no full order ids ever reach the logs, only a prefix.

Current state as of 19 October 2026: source inspection supports the custom protocol description above. It does not establish standard x402 v2 conformance, production reliability, or a successful paid-to-download transaction. RPC availability, independent verification configuration, durable order storage, and product delivery need operational checks. Delivery preflight changes remain in a draft PR; do not treat them as deployed. No paid test was performed for this editorial correction.

Discovery and payment authorization

An MCP interface can support catalogue search, product inspection, comparison, and Stripe Checkout link preparation. A hosted checkout still requires the buyer to review and authorize payment; preparing a link is not native delegated card charging. The custom USDC gateway is a separate integration path. Wallet spending needs buyer authorization and a verified delivery path.