x402 Paid but No Data: How to Diagnose What Actually Failed

If an x402 request appears paid but no useful data arrives, do not immediately retry with a new payment. First establish whether money actually moved, whether the server accepted the authorization, whether settlement completed and whether the response was lost after delivery. Those states look similar from a failed script, but they require different evidence and different remedies.

Stop the retry loop before collecting evidence

Disable the agent, cron job or client loop that is repeating the call. A timeout does not prove that the seller failed to process the request. The first payment may have settled while the final HTTP response was lost, and a fresh retry can create a second authorization or a second transfer. Record the current state before changing wallet balances, headers or request parameters.

Save the six pieces of evidence that matter

Preserve the requested URL and method, the exact time, the request or payment identifier, the original 402 payment requirements, the final HTTP status and headers, and any settlement transaction or facilitator response. Keep the request body or a cryptographic hash if it contained sensitive data. Never send a seed phrase, private key or wallet backup to a seller, facilitator, forum user or supposed recovery agent.

The first decision is whether value moved

A signed payment authorization is not automatically a completed payment. Check the server's PAYMENT-RESPONSE information and the relevant blockchain explorer or channel state. Confirm the network, token, amount, payer, recipient and transaction status. If there is no successful transfer or channel debit, the event belongs in an authorization or settlement-failure category rather than a paid-but-denied category.

Incident state 1: no settlement occurred

The client may have produced a valid signature, but the facilitator could have rejected it, the authorization could have expired, the balance could have changed or the network operation could have failed. In this state, the quoted price was not necessarily lost. Keep the error response, correct the underlying cause and create a new authorization only after confirming that the old one cannot settle.

Incident state 2: settlement succeeded but the response failed

This is the clearest paid-but-no-data outcome. The payment reached the intended recipient, yet the final request timed out, returned an error, produced an empty body or delivered unusable content. The support case should identify one payment, one request and one expected resource. Ask the seller to return the stored result, provide service credit or issue a refund under its published terms.

Incident state 3: two payments exist for one business action

Compare transaction hashes, payment identifiers and timestamps. A network timeout followed by a fresh purchase can produce two settlements even if only the second response reached the client. The x402 payment-identifier extension is designed to support idempotent processing, but the server must actually use the identifier to recognize the retry and return the previous result instead of charging again.

Incident state 4: one payment unlocked the wrong resource

Authorization should be bound to the intended commercial context. Check whether the signed requirements correspond to the expected recipient, amount, network, route, method and expiry. Research published in 2026 demonstrated cross-resource substitution and context-binding weaknesses in evaluated implementations. A valid signature should not be reusable for a different endpoint or a modified business operation.

Incident state 5: verification and settlement disagreed

x402 joins a synchronous HTTP exchange with blockchain settlement that may complete later. A facilitator can regard a proof as acceptable during verification while the later on-chain action fails because of expiry, balance changes, nonce use, reorganization or another state change. A seller that releases the resource too early risks unpaid service; a seller that settles first without a reliable delivery process can create the opposite problem for the buyer.

Incident state 6: variable usage created a disputed amount

The upto scheme allows a buyer to authorize a maximum while the seller settles measured usage. That is useful for inference, bandwidth or variable compute, but it creates a metering question. Compare the advertised maximum, measured usage, final settled amount and returned output. A maximum authorization is not proof that the seller measured correctly or that the result was useful.

A blockchain transaction proves payment, not delivery

An explorer can show that value moved to a recipient. It cannot prove that a specific JSON response, report or model output reached the buyer. Delivery evidence must come from HTTP logs, request identifiers, signed receipts, stored results or another application-level record. x402's signed offers and receipts extension can create verifiable proof-of-interaction artifacts, but support is optional and must be enabled by the service.

The 2026 research identified more than one failure class

Recent studies did not report one universal x402 bug. They described weaknesses across authorization, payment-to-resource binding, replay handling, synchronization between web and blockchain state, facilitator validation and sponsored execution. One paper demonstrated five practical attack classes that could produce unpaid service or paid-but-denied outcomes. Another found cross-resource substitution, duplicate resource delivery and dynamic-pricing failures. A July study of facilitators reported rule violations involving free shopping, denial of service, asset risk and gas-cost abuse. These results apply to tested designs and deployments, not automatically to every current endpoint.

Buyer controls should exist before the first payment

A safe client or agent needs limits that are enforced before signing.

• Approved domains, recipients, assets and networks
• A maximum amount for one call
• A rolling session or daily budget
• Rejection of changed price or recipient details
• One stable payment identifier for every retry of the same request
• A zero-retry default until settlement status is reconciled
• Manual approval for new sellers or unusually expensive calls
• Logs that connect one business action to one authorization and one result

Seller controls should preserve a recoverable result

The server should verify the authorization before expensive work, bind it to the exact resource and reject ambiguous headers or stale requirements. It should process idempotency atomically, retain a successful result long enough for retrieval after a network failure and return structured errors. For non-idempotent operations, payment state and business state must not be updated as unrelated steps.

Facilitator failures can affect many independent services

A facilitator validates proofs and may submit settlement on behalf of many sellers. It therefore needs consistent checks for signature, expiry, chain, asset, amount, recipient and replay state, plus limits on sponsored gas or compute. A flaw in shared infrastructure can have a larger blast radius than a bug in one endpoint, which is why the July 2026 facilitator research matters even to small service operators.

Use an evidence-to-action matrix

Match the observed evidence to the next step.

• No signature and no settlement: fix the ordinary request or wallet setup
• Signature exists but no settlement: investigate authorization, expiry, balance and facilitator errors
• Settlement succeeded and no result arrived: request retrieval, credit or refund from the seller
• Two settlements share one request intent: report a duplicate-charge and idempotency failure
• Recipient or resource changed before signing: treat the request as malicious or misconfigured
• Settled amount differs from measured usage: request the meter record and pricing calculation
• Explorer shows payment to an unknown recipient: stop further payments and preserve all challenge data

A concise support message is stronger than a long accusation

State the endpoint, UTC timestamp, request identifier, expected output, final HTTP status and transaction hash if settlement succeeded. Explain whether the wallet shows one or multiple transfers. Ask whether the service can return the cached result, issue credit or refund the payment. Use only the official support route and redact secrets from screenshots or logs.

Know the recovery limit before paying again

A completed stablecoin transfer is generally not reversed by the blockchain. Recovery depends on the recipient voluntarily refunding, a platform process, escrow, service credit or another contractual mechanism. If the client approved a malicious recipient, the legitimate service may not control the funds. Anyone promising guaranteed blockchain recovery for an upfront fee should be treated as another risk.

Current conclusion

The phrase paid but no data describes an outcome, not a diagnosis. The correct next step depends on whether authorization, settlement and delivery can be tied to the same request. Stop retries, verify the transfer, preserve identifiers and escalate with evidence. The best technical protections are bounded spending, request binding, idempotency, recoverable results and verifiable receipts.

How the evidence was assessed

Official x402 documentation was used for current V2 headers, schemes and extensions. Academic papers were used for experimentally demonstrated attack classes and facilitator findings. The incident workflow is a practical synthesis of those sources and does not claim that any particular failed request was attacked.

Security sources checked on July 28, 2026

Primary protocol documentation and recent research were prioritized.

• x402 HTTP 402 and V2 headers: https://docs.x402.org/core-concepts/http-402
• x402 payment identifier extension: https://docs.x402.org/extensions/payment-identifier
• x402 signed offers and receipts: https://docs.x402.org/extensions/offer-receipt
• x402 payment schemes: https://docs.x402.org/schemes/overview
• Five Attacks on x402 Agentic Payment Protocol: https://arxiv.org/abs/2605.11781
• Free-Riding in the AI Economy: https://arxiv.org/abs/2605.30998
• When HTTP 402 Meets the Blockchain: https://arxiv.org/abs/2607.19545

FAQ