連携する前に
x402 APIを確認。

ウェブサイトではなく、リソースパスを使う。

ライブ検索を開き、完全なURLをx402 endpoint URLに貼り付けます。プロバイダーのホームページを指定しても、そのドメイン上の全APIは検索されません。

このURLには2026年9月6日時点で公開エビデンスがありました。一例であり、推奨ではありません。

支払いネットワークを選び、「Inspect evidence」を実行する。

Base、BSC、0G、Robinhood Chainを選ぶと、保存されたチャレンジ内のメインネットのオプションに絞り込まれます。All networksにはテストネットなども含まれます。プロバイダーは呼び出されず、選択でプロバイダーの受け入れ条件が変わることも、決済が証明されることもありません。

各ディメンションを個別に読む。

所有権

オリジンの管理権限は検証済みか。observedカードでも未検証の場合があります。

プロトコル

支払い不要のレスポンスがx402 v2検査に合格したか。支払い後の結果の検査ではありません。

鮮度

いつ観測され、現在も監視期間内にあるか。

可用性

サンプル数と期間を確認します。測定値がないことは合格ではありません。

プリフライトSDKをインストールする。

Node 20以降またはモダンブラウザを使用します。IFF APIキーは不要です。

チェック済みのfetchを支払いクライアントに渡す。

ラッパーは支払いライブラリが動作する前に402を確認します。ウォレットキーは持たず、支払いも行いません。

import { wrapFetch } from "@ifandonlyif/x402-preflight";

const preflightFetch = wrapFetch(fetch, {
  onDiverged: "throw",
  onStale: "strict",
  onUnobserved: "warn",
});

// Pass preflightFetch as your payment client's fetch.
// Creating this function alone makes no request.

完全な購入処理ではありません。代替：verify()、HTTP API、MCPコマンド。

不確実な状況をアプリでどう扱うか決める。

consistent

比較が一致しています。続行するかは、引き続き自身の支払いポリシーで判断します。

diverged

要件が異なります。この例では支払い処理へ進む前に例外を発生させます。

stale

観測が古い状態です。strictは古い観測と不一致なら例外を発生させ、一致なら警告だけを出します。

unobserved

比較可能な観測がありません。この例では警告を出しますが、自動的には停止しません。

サーバーのログインチャレンジに署名する。

ウォレット認証に従い、チャレンジを要求し、そのメッセージに署名して、アクセストークンとリフレッシュトークンを取得します。トークンは秘密にし、秘密鍵はIFFへ送らないでください。

正確なエンドポイントURLを登録する。

アクセストークンとエンドポイント情報を添えてPOST /api/v3/endpointsを呼び出し、返されたclaim_attempt_idとownershipドキュメントを保存します。登録は申請の開始であり、所有者アクセス権は付与されません。

公開HTTPSのポート443を使用し、認証情報、クエリ文字列、フラグメント、リダイレクトは含めないでください。

所有権ファイルを公開し、検証をキューに入れる。

返されたownership.documentを、指定された正確なownership.verification_urlで配信します。通常は同じオリジン上の/.well-known/iff-trust.jsonです。チャレンジは24時間後に期限切れになります。

1つのオリジンに複数のエンドポイントがある場合は、既存の申請を残し、claims形式で新しい申請を追加します。

POST /api/v3/endpoints/:id/verify-ownershipを呼び出します。202はキュー投入であり、検証済みではありません。結果はGET /api/v3/endpointsで確認します。

監視エビデンスを待ち、通知を追加する。

所有者アクセスと公開エビデンスは別です。verifiedティアの公開には、所有権の確認と少なくとも3回の合格観測が必要です。再確認に備え、所有権ファイルを公開し続けてください。

検証後は、状態や要件の変更についてWebhookを設定できます。一度だけ表示されるシークレットを保存し、各配信の署名とタイムスタンプを検査し、再試行を重複排除してください。

URLではなくJSONを読み込む。

レシートエンベロープか完全なAPIレスポンスを貼り付けるか、JSONファイルを読み込みます。エンドポイントURLはライブ検索で確認してください。解析と署名検査はブラウザ内で動作し、発行者の確認ではIFFの公開鍵ディレクトリを取得する場合があります。

レシートがない場合は、開発者にservice_receiptを含むIFFレスポンスを依頼してください。任意の直接API連携で要求できます。通常のレスポンスには含まれません。

有効な署名と、信頼できる発行者を分けて考える。

署名が有効とは、埋め込まれた鍵が対象に署名したという意味で、ディレクトリとの一致は鍵を識別するだけです。独立したピン留めには、別の信頼できる経路で取得した発行者と完全なsha256:鍵フィンガープリントを指定してください。確認対象のレシートからコピーしてはいけません。

署名対象、時間範囲、バインディングを読む。

署名されたURLと結果が期待どおりか確認します。有効な過去の署名でも、期限切れレシートの場合があります。単独のレシートでは、周囲のレスポンスが署名対象と一致することを立証できません。

レシート署名だけでは、参照された観測、ログへの包含、チェーンアンカーは検証されません。