Testing your agent's spend guard against a hostile 402 seller

Last updated: 14 October 2026.

Short answer: a spend guard is only as good as the seller it meets. Before your agent pays, test it against a seller that lies: a quote that differs from the advertised price, an invoice above your cap, an expired invoice, a second 402 after you have paid, and a malformed header. Your payer should refuse each one before any money moves. Run these offline against a mock wallet that records every payment, and keep one honest seller as a control.

What does a hostile seller send?

A 402 Payment Required reply is a request for money, so a hostile one usually changes a single field:

1. The amount is above the cap. The advertised price is 100 sats; the invoice asks for 10,000.
2. The invoice is already expired, or expires before your payer could pay it.
3. The invoice does not match the resource. It is for a different payee, or its payment hash does not match the challenge.
4. The seller asks for a second payment after you have paid the first.
5. The header is malformed: missing fields, a wrong dialect, or a flood of invoices.

Each case looks like an ordinary error from the payer's side, so a guard that only checks for "a 402" will pay all of them.

What should the payer do?

Check the quote before paying, and refuse it if any check fails:

• the amount is at or under the per-call cap and the daily budget;
• the invoice is for the advertised payee and resource;
• the expiry leaves enough time to pay;
• the payer has not already paid for this resource.

If the guard refuses, it should say why in a log line and return an error to the agent. It should never retry the payment with a larger amount.

How do I test this?

Use a mock seller and a mock wallet. Each case is a fixed reply and a check on what the wallet recorded:

1. Start a mock seller that sends one hostile reply.
2. Point the payer at it, with a cap below the amount the seller asks for.
3. Pass the case if the wallet records no payment, and the payer returns an error.
4. Run the honest control: one fair quote, one payment, one successful response.

Run each case several times with the same input, so a flaky guard shows up.

Is there a ready-made kit?

Yes. Payer Safety Tests has mock sellers and a mock wallet in the L402 and x402 dialects: 14 scenarios, each with an honest control, offline, with no real funds. The mock sellers here are for testing only; they do not sell anything.

FAQ

Why test against a seller that lies, not one that is merely slow?

A slow seller costs time. A lying seller costs money, and that is the risk a spend guard exists to stop. Test the failure that costs the most first.

Does the honest control really matter?

Yes. A payer that refuses every quote passes every hostile case. The control shows that it still pays when the price is fair.

What if the payment goes through, but the seller still reports a failure?

Record the payment, do not pay again, and report the failure to the agent. The wallet log is the record of what was spent.

Can this run in CI?

Yes. The cases need no network and no wallet balance, so they run the same on every machine.

Is this only for L402?

No. The cases cover both the L402 and x402 dialects, because agents meet both.