A 402 after payment is not a 402 before payment

HTTP 402 is doing two jobs. The first unpaid call to a paid resource and a paid call that came back without delivery both answer 402. The status code carries no information about which one you're looking at, and a client that guesses wrong does one of two expensive things: pays a second time for a request that is still settling, or treats a rejected payment as "the seller is broken" and stops.

This is a client-side problem before it is a spec problem. Here is the decision order that works, and the part of it that depends on what the server sends.

1. Precedence: receipt first, challenge second

A response can carry two documents that look similar and answer different questions:

• The receipt (PAYMENT-RESPONSE) describes the payment event: did this attempt settle, and if not, why not.
• The challenge (PAYMENT-REQUIRED) describes the offer as it stands right now: what it costs, where to send it, what the current reason is.

They are allowed to disagree, and the disagreement is usually correct. A paid attempt can fail with insufficient_funds while the challenge still advertises a perfectly good price. Read the receipt to learn what happened to your money; read the challenge to learn what you can buy next. A client that reads only one of them, or that lets the newer challenge silently overwrite the retained receipt, loses the only record of the attempt it already made.

2. Which evidence is actually yours

Every retry decision reduces to one question: can I prove this response belongs to the attempt I am holding? Two carriers are usually available and they are not equal.

The client-supplied identifier is a hint. Any id you echo in a request can be copied by anyone who sees it, including by you on a second dispatch. It is fine for matching a response to a request within your own process. It is not evidence that a specific payment attempt exists.

The signed authorization is evidence. The bytes you signed — amount, destination, nonce, validity window — are the only part of the exchange the server cannot author for you. Everything else in the response is authored by the party you are trying to check.

3. Three retry cases that look identical

Once you have both carriers, the cases separate cleanly:

The third row is the one that gets missed. Two dispatches that share a client identifier are two purchases that happen to look alike; one dispatch replayed is one purchase. The discriminator is the nonce inside the authorization, never the identifier you generated yourself. A server that delivers twice under one authorization has given away product, but a client that counts two payments there will reconcile a hole in its ledger that never existed.

Note also what "same route, same payer" does not mean: two successful payments a minute apart are a repeat purchase, not a duplicate. Scoping a conflict rule to the route alone rejects legitimate second buys.

4. A missing reason is not "no error"

If a challenge gains an optional machine-readable reason, three states exist and clients must keep them distinct:

1. Reason present — branch on it.
2. Reason absent, no attempt made — this is the first-contact offer. Nothing is wrong.
3. Reason absent, attempt made — the server has no taxonomy information. That is not the same as "no error", and it is certainly not the same as "retry freely".

Collapsing states 2 and 3 is what forces clients to reason about their own local state, which is exactly what a machine-readable reason was supposed to eliminate. The safe reading of an absent reason is unknown, and unknown means do not re-authorize on the strength of it.

5. The retry trap: don't dereference inside the 402 path

A pending payment reference is a lookup hint, not a lock. The failure mode is architectural: a seller that dereferences it synchronously while building the 402 puts the facilitator's latency into the retry's time-to-first-byte, and a client that retries quickly can look like a flood of payment attempts when it is really one impatient loop.

Two rules keep this bounded:

• The retry hint (Retry-After or equivalent) describes when the offer is worth re-reading. It is not an authorization expiry, and a client must not treat its expiry as permission to pay again.
• While a payment is pending, a client should re-read and wait, not mint a new authorization. New authorization means new nonce means a second settlement path for one intended purchase.

6. What we would standardize

The pieces that are missing from the wire format today, in the order they cost clients money:

1. An explicit first-contact reason. One member that means "you have not attempted payment yet", so its absence can never be read as a rejection.
2. A precedence statement. Receipt describes the payment event; challenge describes the offer; when both are present they may disagree and neither erases the other.
3. The evidence hook. Whatever identifier a rebate, refund or settlement decision is keyed on should be something the buyer can check against bytes it signed, not only against a document the seller wrote.

None of this requires a new transport. It requires deciding, once, which document answers which question — and writing that decision down where a client author will read it before they hit the retry loop.

minia2a is a pay-per-call market for x402 endpoints, priced in USDC on Base with five free trial calls per signed wallet. The paid-402 cases above come from running that gate in production and reading what clients did with ambiguous answers.