x402 で支払ったのに届かないとき、402 から分かるのは「売り手が失敗時の扱いを宣言したか」だけです。実際に当方の /gas の 402 を無料の /failure/sample で読むと、4項目のうち宣言があったのは timeout 1つだけ（maxTimeoutSeconds=60）で、error_shape・retry・refund は未宣言、missing[] に3項目が入っていました。返金の約束も再試行の条件も、402 には書かれていません。
これは「返金しない」という意味ではありません。宣言が無いので、402 からは返金の有無を読めないという意味です。未宣言を「無い」と読み替えないのがこの道具の設計で、missing[] がその差を残します。
納品されたかどうかも、売り手の /status だけでは分かりません。当方の実測では 39 経路中 26 経路が納品0件でしたが、これは「失敗した」ではなく no_data（記録が無い）です。納品ログは 200 の納品だけを記録し、fail_24h は常に null です。届かなかったことの証拠は、自分の支払いトランザクションと売り手の記録を突き合わせるまで確定しません。
| 経路 | 条件 | 応答 | 本文 | 応答時間 |
|---|---|---|---|---|
/failure/sample | 無料 | 200 | 3,184 B | 648 / 163 / 153 ms |
/failure?url=…/gas | 未払い | 402 | 25,673 B | 262 / 490 / 167 ms |
/check?url=example.com/x | 未払い | 402 | 26,993 B | 282 / 217 / 186 ms |
/status | 無料 | 200 | 19,807 B | 8,433 ms |
/openapi.json | 無料 | 200 | 141,345 B | 426 ms |
/ja | 無料 | 200 | 58,174 B | 176 / 192 / 180 ms |
/failure は 0.05 USDC で、未払いの GET には 402 と payment-required ヘッダ 5,336 B を返します。同じ 0.05 USDC の /check は 402・26,993 B・ヘッダ 5,664 B でした。402 本文の大きさは価格では決まらず、対象や説明の量で変わります。
支払わずに読める /failure/sample は 200・3,184 B で、初回 648 ms、2回目 163 ms、3回目 153 ms。ウォーム後は 153〜163 ms です。同じ時刻の /openapi.json は 48 paths を含む 141,345 B・426 ms で、/failure と /failure/sample の両方が載っています。
/status だけが 8,433 ms と大きく遅い結果でした。1回だけの計測で、原因は未確認です。
/failure/sample が読んだのは、当方の /gas の 402（PAYMENT-REQUIRED ヘッダの base64 JSON を優先）です。返ってきた宣言は次の4項目に分かれます。
| 項目 | 宣言 | 読めた内容 |
|---|---|---|
error_shape | false | フィールド0件・必須0件。失敗時に何が返るかの形は書かれていない |
timeout | true | accepts[0].maxTimeoutSeconds = 60（支払いの期限であって、応答の期限ではない） |
retry | false | 再試行の文言もキーも無い |
refund | false | 返金の文言もキーも無い |
missing[] は [\"error_shape\", \"retry\", \"refund\"] の3件。x402Version は 2、declared は true（402 自体は読めた）です。つまり「x402 であることは読めるが、失敗した後のことは読めない」という状態です。
ここで注意が2つあります。1つ目は、declared:false は「返金しない」ではないこと。宣言が無いだけで、売り手が別のページや規約で返金を約束している可能性は残ります。2つ目は、maxTimeoutSeconds は支払いの期限で、応答が60秒で切れるという意味ではないこと。この道具はそこを読み替えず、timeout の note にもそう書いています。
/failure?url=… は、この4項目を他人の 402 についても読む有料の経路です（0.05 USDC・1回の GET）。対象の 402 を1回だけ読み、推測はせず、読めたパスだけを返します。今回は支払っていないので、200 の本文は未取得です。
「届かなかった」を確かめる材料として、無料の /status（19,807 B）を同じ時刻に読みました。全体は 39 経路で、routes_with_data は 13、納品記録がある経路の合計は 60 件。残る 26 経路は納品0件で、data_status は no_data でした。
納品が多い順は /history 26件、/price 7件、/gas 6件、/check 5件、/reality 4件。overall.last_success は 2026-10-18T03:00:46.740Z、success_24h は 5 です。
ただし、これは失敗率ではありません。/status が記録するのは「有効な支払いの後に 200 を返した納品」だけで、fail_24h は常に null（データが無い、0ではない）です。26 経路の納品0件も、買われなかったのか、買われたが届かなかったのか、この記録だけでは区別できません。「記録が無い」を「死んでいる」と読み替えないのがこの面の設計です。
同じ /status が 8,433 ms かかったことも、失敗の証拠にはなりません。1回の計測で、遅い理由は未確認です。
error_shape・retry・refund が宣言されているか、missing[] に何が入るかを見ます。当方の /gas は timeout 以外が未宣言でした。未宣言なら返金の約束は 402 には無いと扱い、払う金額を1回分に抑えます。/failure/sample は 200・3,184 B・153〜163 ms（ウォーム時）で、同じ形を無料で返します。有料の /failure を買う前に、返る項目と missing[] の読み方を確認できます。/status で、その経路に last_success と deliveries_observed があるかを見ます。無ければ no_data であって、失敗の証明ではありません。自分の支払いトランザクションの時刻と、売り手側の記録の時刻を並べます。当方の /failure は 0.05 USDC で存在しますが、facilitator の listing-status は 404（カタログ未掲載）でした（/failure/sample も 404）。カタログから辿る買い手には見つからないので、この記事と /openapi.json が入口になります。掲載状況は2026-10-19時点の実測です。
200 の本文は取得していません（支払い・SMS・KYC は行わない制約）。したがって、/failure を買ったときに返る実際の JSON、他人の 402 に対する判定の精度、retry や refund が宣言されている売り手の実例は未確認です。数字はすべて「402 が返るところ、無料の 200 が返るところ」までの実測です。
/status の 8,433 ms がコールドスタートか負荷かは特定していません。26 経路の納品0件も、未購入と未納品のどちらかは分かりません。
買う前の確認手順は /ja/check-before-paying、相手の仕様変更は /ja/schema-change、価格の相場は /ja/price-benchmark に実測でまとめています。API の形は無料の /openapi.json（48 paths）で読めます。