Payment lifecycle

1. Resolve and negotiate

The payer turns an x402pay:// reference into the gateway's HTTPS receive URL. A request without PAYMENT-SIGNATURE returns 402 Payment Required and binds the resource URL, network, chain id, USDC contract, amount, payTo, and validity window.

2. Verify before signing

The payer SDK validates the response against the original reference. In production it requires a signed offer by default, discovers the gateway DID document, and checks the signer, origin, payment identifier, and payment context.

3. Authorize

The wallet signs TransferWithAuthorization typed data. The nonce and validity window make the authorization bounded and replay-resistant. The wallet remains the only component with access to payer keys.

4. Verify and settle

The gateway validates the submitted payload, calls facilitator /verify, then /settle. The facilitator broadcasts the transaction; the gateway never receives custody of the funds.

5. Prove and recover

A successful response includes a tx hash and can include a signed receipt. Merchants should verify chain confirmations before irreversible fulfillment. If settlement succeeded but receipt signing or persistence failed, POST /recover-settlement can reconstruct the result without settling a second time.

Idempotency

payment-identifier is bound to a fingerprint of the payment context. Reusing an identifier for a different payTo, amount, asset, network, or resource must fail closed. Business systems still need to assign identifiers according to their own fulfillment policy.