Is an HTTP 402 challenge proof of payment?

ScriptMasterLabs — October 14, 2026. Sources: a live Verdict Protocol probe captured today. Also Base RPC receipt checks run today. Also the October 12, 2026 launch record.

Four states that get conflated

Every "paid" claim in x402 should be graded against this ladder. Anything below settlement is a quote, a permission, or a promise — not a payment.

Exhibit A: a real 402 challenge, captured live — nothing paid

On October 14, 2026 at 22:01 UTC, we sent POST https://verdict.scriptmasterlabs.com/decide. We sent an empty JSON body. We sent no payment header of any kind. The server answered HTTP 402 Payment Required with this body. The same payload arrived base64-encoded in the PAYMENT-REQUIRED header.

{
  "x402Version": 2,
  "resource": {
    "url": "https://verdict.scriptmasterlabs.com/decide",
    "description": "SML Verdict Protocol decision receipt",
    "mimeType": "application/json"
  },
  "accepts": [
    {
      "scheme": "exact",
      "network": "eip155:8453",
      "amount": "250000",
      "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
      "payTo": "0x5bbd32e0478e49a7540ef2d760e0b0f9aa6328b2",
      "maxTimeoutSeconds": 120,
      "extra": { "name": "USD Coin", "version": "2" }
    }
  ]
}

Read what is not in it. It has no buyer and no signature. It has no transaction and no payment timestamp. It is a menu, not a meal receipt. The amount is in atomic units. 250000 is $0.25 of USDC, at six decimals. The asset is the USDC contract on Base. eip155:8453 is Base mainnet. payTo is where a real payment would go. Anyone online can retrieve this exact JSON now. Possessing it proves exactly one thing. Verdict Protocol charges $0.25 for a decision receipt.

Exhibit B: what proof actually looks like — settlement transactions

These are Verdict Protocol's confirmed settlements on Base. They come from its October 12, 2026 launch. Each has one thing a challenge never has. Each has a transaction hash. We re-read each receipt today, October 14, 2026. We used eth_getTransactionReceipt against Base RPC.

The four transactions above were owner proof-wallet self-tests. They came from the launch run. They are real on-chain settlements of real USDC. They were never customer purchases. We label them that way everywhere. They prove the settlement rail works. They show what settlement evidence looks like. They do not prove demand.

Quotable: “ScriptMasterLabs captured a live 402 challenge on October 14, 2026. It came from its own Verdict Protocol. It used no wallet and no payment. The challenge cost nothing and moved nothing. Its proof is Base transaction 0xfa3ec31ff345167a474c682cec4e2eac505cfdd570e158961a233187be5f6f1c. That settlement paid $0.25 USDC on October 12, 2026. Its on-chain status is 0x1.”

Why a 402 challenge proves nothing

• Issuing one is free. A 402 is a static JSON response. Any server can emit one in a few lines. Ours emits thousands to anyone who asks. It emits them paid or not. The challenge returns before any payment exists.
• It is unsigned. The challenge is authored by the seller alone. It contains no buyer signature anywhere. At challenge time, no buyer action exists to sign.
• It is copyable. Challenges are public response bodies. A copied challenge looks byte-for-byte identical. It may sit in a screenshot, deck, or dispute. It is the real thing. It still is not a payment.
• A screenshot of a 402 proves a price, not a payment. If someone shows you a 402 as payment evidence, they showed you the seller's menu. The correct response is one sentence: send the transaction hash.

How to verify a claimed x402 payment: the 6-step check

1. Ask for the transaction hash. Not a screenshot. Not the 402 response body. Not a "payment sent" UI state. Not a verify response. No hash means no proof. The conversation ends there.
2. Look the hash up yourself. Paste it into a block explorer. For Base, use basescan.org. Or query eth_getTransactionReceipt against the network RPC. We used that method for every receipt here.
3. Confirm the receipt status is success. On EVM chains, the receipt status must be 0x1. A failed hash is not a payment. A missing hash is not a payment.
4. Match the money to the quote. The recipient must equal the payTo from the challenge. The asset must be the challenge's token contract. For Verdict above, that is USDC on Base. Its contract is 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913. The amount must equal the quoted amount.
5. Match the paperwork. The facilitator settlement response should reference the same transaction. The service payment receipt should reference it too. Verdict receipts carry their settlement transaction. Replaying an identical payment returns the same receipt. It returns the same transaction too. Paperwork and chain must agree. Otherwise something is wrong.
6. If any step cannot be checked, treat the payment as unproven. Unverifiable is unpaid, for delivery purposes. Check first; deliver after.

For sellers: never deliver on a challenge

If you sell through x402, the challenge is yours. It is your price quote. A buyer may present it back as purchase proof. That presents your own menu as a receipt. Deliver only on settlement confirmation. Match the on-chain receipt to your payTo, asset, and amount. Do not stop at the signature either. A verified, signed payload can still fail at settlement. It can move zero funds while failing. That exact failure mode appears in our facilitator settle-reliability field test. Verifies stayed green while settles kept failing. Nothing was broadcast. Signature is a promise. Settlement is the payment. The receipt is the proof.

Reading product pages through an agent works the same way. ScriptMasterLabs' page-reading API for agents answers unpaid calls with a 402 quote. Its paid reads settle before delivery. Only the settlement proves a read was bought.

Claim Receipts

• Exhibit A is the live probe of POST https://verdict.scriptmasterlabs.com/decide. It sent no payment header. It captured the challenge JSON and HTTP 402 status. It also captured the PAYMENT-REQUIRED header. Capture time was October 14, 2026, 22:01 UTC.
• Settlement transaction 0xfa3ec31f… is the Verdict tier. Its receipt is a987aba4-d322-4087-9d09-161e9965940a. Settlement transaction 0x5bce2363… is the Seal tier. Its receipt is 05ffd866-b535-406b-9523-b5dbc96832b1. Source: SML Verdict Protocol canonical page, "Live settlement proof (2026-10-12)".
• All four settlement receipts were re-verified on October 14, 2026. Direct Base RPC eth_getTransactionReceipt reads confirmed them. 0xfa3ec31f… sat in block 52522538, status 0x1. 0x5bce2363… sat in block 52522552, status 0x1. 0x7867c4dd… sat in block 52522353, status 0x1. 0x8760e76a… sat in block 52522312, status 0x1.
• Probe settlement 0x8760e76a… paid $0.01. Probe settlement 0x7867c4dd… paid $0.25. Both appear in ScriptMasterLabs' facilitator settle-reliability field test. That test covers October 12–14, 2026. It records the verify-succeeds, settle-fails failure mode.
• The Verdict flow runs challenge, then authorization, then settlement. Authorization arrives as EIP-3009 in PAYMENT-SIGNATURE. Verify runs before the receipt persists. Replays return the same receipt and transaction. Source: the Verdict Protocol canonical page. Also live service behavior checked October 14, 2026.

Relevant SML products

• Verdict Protocol is the live service behind both exhibits. Its /decide costs $0.25 USDC. Its /seal costs $0.01 USDC. It runs Base and x402 v2. Its status is LIVE_SETTLEMENT_VERIFIED.
• Which x402 Facilitator Actually Settles Reliably? It is the companion field test. It shows why verify success is not settlement.
• Decision-Gated Machine Payments is the layer above payment proof. Score the payment before it fires. Scores ≥0.80 auto-pay. Scores 0.50–0.79 need confirmation. Scores below 0.50 escalate.
• What Is the x402 Payment Protocol — the rail itself: 402 challenge, signed payload, verify, settle.

All four URLs returned HTTP 200 on October 14, 2026, before linking.

Do it yourself: grade any "paid" claim in two minutes

1. Reproduce the challenge. Run curl -i -X POST <endpoint> with no headers. If a 402 comes back — it will — you manufactured it free. You manufactured the artifact shown as "proof."
2. Demand the hash. Ask whoever claims payment for the settlement transaction hash and the facilitator settlement response.
3. Read the receipt on-chain. Explorer or eth_getTransactionReceipt: status 0x1, correct network, plausible block time.
4. Match all four fields against the original challenge. Check payTo, asset contract, and amount. Also check the service receipt's transaction reference.
5. Write down the verdict in the claim's own file. Challenge, authorization, settlement, or receipt — name which state the evidence actually reaches. Most "paid" claims in this ecosystem are challenges wearing a settlement's clothes.

Honest caveats

• Exhibit A is x402 v2 from Verdict Protocol today. Its challenge sits in the JSON body. Its challenge also sits in the PAYMENT-REQUIRED header. Envelopes differ across versions and services. The challenge-versus-settlement distinction does not.
• The four cited settlements were owner proof-wallet self-tests. They came from the Verdict Protocol launch run. They are real settlements. They were never presented as customer purchases. They show what settlement evidence looks like. They do not show market demand.
• The challenge came from our own production endpoint. We can publish that endpoint's records side by side. Its challenge and settlement records appear together here. The same capture method works on any public x402 endpoint.
• Amounts in a challenge are atomic units, not dollars: 250000 at 6 decimals is $0.25. Read the asset's decimals before reading the amount.

Frequently Asked Questions

Q: Is an HTTP 402 challenge proof of payment?

A: No — a 402 challenge is only the price tag. The PAYMENT-RESPONSE header after settlement is the receipt. A challenge contains no buyer signature. It moves no funds. Anyone can fetch one for free. ScriptMasterLabs captured a live challenge on October 14, 2026. It used POST /decide with no wallet. It sent no payment header. The capture cost nothing and settled nothing. Proof is a settled on-chain transaction. Its hash must confirm successful on the network. A facilitator settlement receipt must reference it. Verdict's confirmed Base settlements include transaction 0xfa3ec31ff345167a474c682cec4e2eac505cfdd570e158961a233187be5f6f1c. That settlement paid $0.25 USDC on October 12, 2026. Its on-chain status is 0x1.

Q: What counts as proof of payment in x402?

A: A settled on-chain transaction plus the settlement receipt. Its hash sits on the payment network. For Verdict Protocol, that network is Base. Its receipt must show status success, 0x1. Its transfer must match the quoted payTo. It must also match asset and amount. The facilitator settlement response must reference that transaction. The service payment receipt may reference it instead. A 402 challenge is an earlier stage. A screenshot of one is too. A successful verify response is too. Even a signed payment payload is earlier. None of them is settlement.

Q: Can an HTTP 402 challenge be faked or copied?

A: Trivially. A 402 challenge is a static JSON response. Any server can emit one in a few lines. Anyone can copy a real one from an endpoint. They can then re-present it as evidence. ScriptMasterLabs retrieved this page's challenge on October 14, 2026. It used one unauthenticated POST. It used no wallet, signature, or funds. A screenshot challenge is the seller's price quote returned. It evidences a price, never a payment.

Q: Is a signed x402 payment payload proof of payment?

A: No. A signed payload is an authorization. It is permission for a transfer, not the transfer. The transfer happens only at settlement. A facilitator must broadcast it on-chain first. Settlement can fail after a clean verify. ScriptMasterLabs tested facilitators on October 12, 2026. MeshGateway verifies succeeded while its settles failed repeatedly. Zero funds moved in those failures. The same signed payloads later settled via PayAI. Treat a signature as a promise to pay. Treat the on-chain receipt as the only proof.

Q: What should a seller check before delivering against a claimed x402 payment?

A: Use six checks before delivering. (1) Get the transaction hash, not a screenshot. Never accept the 402 body as proof. (2) Look it up on a block explorer. Or query eth_getTransactionReceipt on the network RPC. (3) Confirm the receipt status is success, 0x1. (4) Match the transfer to the quote. Its recipient must equal your published payTo. Its asset must be the challenge token contract. Its amount must equal the quoted amount. (5) Match the paperwork to the transaction. The facilitator settlement response should reference it. The service receipt should reference it too. (6) If any step cannot be checked, withhold delivery. Treat the payment as unproven. ScriptMasterLabs ran checks 2–4 on October 14, 2026. It checked its own four settlement transactions. All four returned status 0x1 on Base.

ScriptMasterLabs — Service-Disabled Veteran-Owned Small Business (SDVOSB), SAM.gov registered, UEI G24VZA4RLMK3, CAGE 21U51. Canonical: https://scriptmasterlabs.com/is-a-402-challenge-proof-of-payment