Paid and blocked: why your agent still gets a 402 after paying

The x402 flow is three steps: the server answers 402 Payment Required with machine-readable payment requirements, the agent pays, the server verifies and serves. When it works, there is nothing to debug.

Then one day your agent pays, the payment settles, and the retry comes back with a fresh 402. Or verification rejects a payment that looks correct. Or the money is on-chain and the resource never arrives.

This is the failure state x402 builders call paid and blocked, and it is worse than an ordinary error because of how the protocol is shaped: x402 is synchronous and terminal. There is no escrow, no result hash, and no on-chain refund path. A failed paid call has no built-in recourse, which means diagnosis is not a nice-to-have — it is the only move you have. This article is the diagnostic order: four failure modes, how to tell them apart, and what fixes each one.

1. The second 402: you paid in the wrong protocol version

Symptom. The payment verifies or settles, you retry the request with proof of payment attached, and the server returns 402 again as if you never paid.

Likely cause. A header version mismatch. x402 v1 servers expect the payment proof in an X-PAYMENT header. v2 servers expect PAYMENT-SIGNATURE. Send the wrong one and the server does not reject your payment — it simply never sees it, so it does the only thing it can do: issue a new 402. From the server's side, your retry is indistinguishable from a first request.

How to verify. Log the exact header your client sent on the retry, and decode the 402 response to see which protocol version the server's payment requirements declare. If the versions differ, you have found it — no amount of re-paying fixes a header the server isn't reading.

The fix. Send the header the server's version expects, and pin the protocol version on both sides of the integration. This failure is silent and repeatable, which makes it the most common cause of "402 again after paying" — and the cheapest to fix once identified.

2. Verification rejects a payment that looks right

Symptom. The server (or its facilitator) refuses the payment outright. No settlement, no resource, and an error that tells you less than you need.

Likely causes. x402 verification is exact, in the literal sense:

• Amount mismatch. The amount must match the requirement exactly. Overpaying or underpaying by 1 wei fails verification. A client that rounds, converts units loosely, or adds a buffer is wrong in a way that looks like "I paid more than asked, why did it fail?"
• Wrong chain ID in the EIP-712 domain. The payment authorization is a signed typed message; if the domain's chain ID doesn't match the network in the payment requirements, the signature is invalid for that requirement no matter how correct everything else is.
• Invalid signature or insufficient funds. A malformed signature fails, and so does a wallet that doesn't hold enough USDC to cover the payment.
• A KYT flag. A payment can be refused on compliance screening even when the cryptography and the balance are both fine.

How to verify. Compare the amount in your payment payload against the requirement in base units, digit for digit. Check the chain ID in the signed domain against the network the 402 specified. Confirm the paying wallet's balance covers the payment. If a facilitator verified the payment, read its actual response — a rejection carries a reason, and guessing past it wastes hours.

The fix. Match the requirement exactly: same amount in base units, same network, same asset. Treat "close enough" as a bug class in payment code, because the verifier does.

3. The facilitator said no — or said nothing

Symptom. Your payment never reaches the server's verifier at all, or comes back rejected from the intermediary.

Likely causes. Most x402 verification runs through a facilitator, and facilitators fail in their own ways: a rejection with a stated reason (CDP's facilitator answers include a rejectedReason — read it before changing anything), facilitator downtime, or a deployment mismatch such as pointing a testnet facilitator at a Base mainnet requirement it doesn't support.

How to verify. Capture the facilitator's raw response, not just your client's summary of it. Confirm the facilitator endpoint in your configuration actually serves the network named in the payment requirements.

The fix. Act on the stated reason. A rejectedReason is the facilitator telling you which of the failure modes in section 2 you are actually in. And log facilitator responses permanently — a rejection you didn't record is a failure you'll have to reproduce from memory.

One related trap, for sellers reading this from the other side: failed payments never settle, so they never appear in settlement data. If you only watch settled payments, rejected attempts are invisible to you. Buyers experience those invisible failures as "I paid and nothing happened."

4. Payment settled, nothing delivered

Symptom. This is the bad one. The payment is settled on-chain. The resource — the report, the data, the completed action — never arrives. There is no pending state to wait out.

Likely cause. An ordering bug on the seller's side, documented in seller postmortems: the server settles the payment before doing the work, the work then fails, and the buyer is left with a settled payment and no output. Because x402 has no escrow and no on-chain refund path, the buyer's only remedy in the standard flow is the seller issuing a manual refund.

How to verify. Assemble the evidence before you contact anyone: the payment requirements you were given, the payment payload you submitted, the settlement transaction, and the server's response to your paid request. You will notice the gap immediately: a transaction hash proves a payment happened. It does not prove who paid it, what it was for, or that you are the party entitled to the undelivered resource. Anyone can copy a hash out of a block explorer.

What fixes it. Honesty first: no client-side tool can force a seller to deliver or refund, and nothing retrofits an escrow into a settled payment. What you can do is arrive with evidence instead of an anecdote — and where a seller supports redemption, prove you are the payer with a signature, not a screenshot of a hash. That distinction is the entire recovery game in x402, and it is where tooling earns its place.

Where callx402 fits: the recovery case

We built callx402 (by Payload, powered by Veyline) for exactly the state this article describes. Two properties shape everything it does:

• The diagnostics are read-only by design. The six MCP tools — x402_status, x402_diagnose, x402_evidence, x402_explain, x402_recover, x402_resolve — never charge, execute, retry, or repay. They answer the questions sections 1–4 leave you with: which failure is this, what does the evidence show, and what is the recovery path for it.
• There is no key custody, in any version, and the package has zero dependencies. A diagnostic tool has no business holding your keys, and this one structurally can't.

The recovery case is signed redemption. In callx402 1.0.3, redeeming what you paid for requires EIP-191 wallet-signed payer authorization: you sign with the wallet that paid, and the signature — not a transaction hash — is the credential. A tx hash alone is rejected server-side, deliberately, because a hash is public information and proves nothing about who is asking. If you take one practice from this article, take that one: wherever you redeem a paid action, expect to sign, and be suspicious of any flow that treats a bare hash as proof of entitlement.

For agent workflows that would rather call than install, callx402 also exposes nine hosted actions. The package is on npm as callx402@1.0.3, and the same six tools are listed in the official MCP registry.

What callx402 does not do, stated plainly: it does not custody funds, execute trades, or move money on your behalf, and it cannot guarantee a recovery — if a seller settled and vanished, the protocol gives nobody a lever to reverse that. What it gives you is the diagnosis, the evidence assembled in one place, and a redemption path that verifies the right person is asking.

The checklist

When an agent reports paid-and-blocked, work this order before re-paying anything:

1. Which header did the retry carry — X-PAYMENT or PAYMENT-SIGNATURE — and which version does the server require?
2. Does the amount match exactly, in base units, against the 402's requirement?
3. Does the EIP-712 domain chain ID match the network in the requirements?
4. What did the facilitator actually say — is there a rejectedReason on record?
5. Did it settle? If yes and nothing arrived, stop retrying: gather the requirements, the payload, the transaction, and the response. You are in the evidence-and-redemption case now, not the retry case.

Most paid-and-blocked incidents resolve at step 1 or 2. The rest are only solvable if you kept the evidence — so keep it from the first request, not after the first failure.

The seller-side companion to this article — the failure modes that originate in the server implementation itself — is x402 in production: the failure modes nobody warns you about.