securityreplayidempotency

Updated 2026-07-06

Security and Reliability Checklist

x402 makes payment easy to attach to HTTP. That does not make payment easy to secure. The main risks are replay, wrong destination, wrong amount, unlimited wallet authority, unclear refunds, and retry ambiguity.

Server checks

The resource server should treat every paid request as an authorization boundary. Do not serve the resource because the header exists. Serve it because the payload verifies against the exact requirements for this route, method, amount, destination, network, asset, and scheme.

If you use a facilitator, verify the integration path and error handling. If you implement locally, read the scheme specs. Network-specific edge cases such as Solana duplicate settlement or token metadata mismatches are not optional details; they are part of payment correctness.

  • Reject mismatched method, path, amount, asset, network, or destination.
  • Bind payment requirements to the resource being purchased.
  • Apply idempotency for retries and response caching.
  • Log settlement IDs and decoded error reasons without storing private keys.

Client checks

Buyer software should defend the wallet. An agent can be tricked by tool output, malicious links, DNS issues, price changes, or repeated 402 challenges. The client has to check that payment terms fit the user or system policy before signing.

The most dangerous anti-pattern is a hot key with no spend cap. Even if every x402 message is valid, an autonomous client can spend too much if it lacks budgets, allowlists, or human approval thresholds.

  • Set max price per request, max daily spend, and allowed hosts.
  • Choose allowed networks and assets explicitly.
  • Persist payment IDs for retryable paid operations.
  • Expose decoded payment terms in logs or UI before high-value signatures.

Business checks

Exact payments are push payments. Refunds are therefore not automatic chargebacks; they are a new business transaction or a scheme-specific mechanism. That has product implications. Support teams need a way to find a payment, verify whether a resource was delivered, and decide whether to refund.

For B2B APIs, buyer procurement may still need invoices, receipts, tax reporting, spend limits, and customer-level dashboards. x402 can remove subscription friction for the request path, but it does not remove every commercial requirement around paid software.

FAQ

What causes repeated 402 responses after payment?

Common causes include invalid signatures, wrong chain IDs, exact amount mismatch, insufficient token balance, or KYT/provider rejection. Clients should inspect structured errors.

Is idempotency mandatory?

It is not always mandatory in the protocol, but production paid endpoints need a retry story. The payment-identifier extension is the clearest standardized path.