What is 402 Retry Logic?

The x402 protocol's core flow is a two-step interaction: the client first requests a resource and receives 402 with payment requirements, then retries with a payment signature attached. This retry is fundamental to how x402 works — it's not an error recovery mechanism but the normal payment flow.

The standard retry flow:

1. Client sends GET /resource
2. Server responds 402 Payment Required with PAYMENT-REQUIRED header
3. Client constructs payment payload matching the requirements
4. Client re-sends GET /resource with PAYMENT-SIGNATURE header
5. Server verifies, settles, and returns 200 with resource

The x402 spec notes that steps 1-2 are optional if the client already knows the payment requirements — allowing a single-request flow for repeat purchases from known endpoints.

However, retry logic becomes dangerous when combined with autonomous agents and error states. If the server returns an error after payment (500, timeout, malformed response), a naïve retry loop pays again and again. PolicyLayer's analysis identified this as the infinite payment loop threat — a production system called GetOnStack once entered a recursive loop for 11 days, costing $47,000 in API costs. With x402, each retry costs real money.

Safe 402 retry logic requires: maximum retry counts, duplicate payment detection, exponential backoff, and per-endpoint circuit breakers.

PolicyLayer's duplicate detection prevents the most dangerous retry failure mode — paying twice for the same resource. If an agent retries a request to the same endpoint within a configurable time window, the second payment is blocked. The circuit breaker pauses all payments after consecutive failures.