x402 protocol

Base USDC payments, receipts, failures, and safe retries

SignalHarness accepts x402 V1 and canonical x402 V2 exact payments on Base mainnet. The live challenge—not a copied address—defines the recipient, amount, asset, network, expiry, method, and resource for each call.

Payment sequence

Send a schema-valid POST without payment.
Receive HTTP 402: V2 clients decode PAYMENT-REQUIRED; V1 clients read the equivalent JSON body.
Validate the exact Base USDC requirement against budget and authority.
Sign with a compatible buyer client.
Retry the identical request with exactly one header: PAYMENT-SIGNATURE for V2 or X-PAYMENT for V1.
SignalHarness verifies, settles, checks finality, records the receipt, and executes once.

Receipts and completion

A successful V2 response includes PAYMENT-RESPONSE; a successful V1 response includes X-PAYMENT-RESPONSE. Both use the same service response and server-side receipt and recovery controls. A redirect, accepted signature, or transport handoff alone is not proof that payment or delivery completed.

Failure states

402: no acceptable payment evidence; no service execution.
4xx: invalid method, schema, size, payment, or replay; correct the request before authorizing anything new.
202: payment or finality is pending; do not create another payment.
409: conflicting or replayed operation; recover with the same payment and same request only.
5xx/timeout: outcome may be uncertain; preserve the request and payment identity.

Safe retry rule

If the outcome is uncertain, resend only the identical service ID, method, body, and previously authorized payment evidence. SignalHarness idempotency and same-payment recovery can return the existing outcome. Never sign a second payment until the first payment is authoritatively failed or expired and the owner separately authorizes another spend.