Skip to main content
API リクエストごとに直接支払う方法に加えて、Ace Data Cloud は X402 でコンソール注文を支払うこともサポートしています。注文支払いと API 呼び出しのコアプロトコルは同じです:最初のリクエストは 402 を返し、クライアントが PAYMENT-SIGNATURE に署名してから、同じリクエストで再試行します。 違いは、注文支払いはアカウントトークンを必要とするプラットフォーム API であることです。一方、x402.acedata.cloud の AI API を直接呼び出す場合は、X402 のみを使用でき、API Token は不要です。

注文を準備する

Ace Data Cloud コンソールにアクセスし、支払いが必要な注文を選択して、注文 ID を記録します。 まだ注文がない場合は、プランページで未払い注文を作成できます。注文価格はページに表示される内容に従い、X402 の 402 レスポンス内の amount が最終的な署名根拠となります。

アカウントトークンを作成する

注文支払いリクエストにはアカウントトークンが必要です。プラットフォーム Token ページを開き、platform-v1-... 形式の token を作成します。 以降のリクエストでは以下を使用します:
アカウントトークンは通常の API Token とは異なります。通常の API Token は API クレジットの消費に使用されます。アカウントトークンは、注文支払いなどのプラットフォームリソースを、あなたのアカウントを代表して操作するために使用されます。

402 をトリガーする

まず、PAYMENT-SIGNATURE を付けずにリクエストを 1 回送信します:
ステータス 402 が返され、レスポンスには accepts が含まれます:
注文支払いでは公式 x402 v2 を使用します:x402Version は 2、network は CAIP-2 識別子を使用し、金額フィールドは amount です。 10 Credits の注文を作成して 402 をトリガーしたプログラム実行結果:
以下の取引記録は旧ポリシー下における過去の実測サンプルであり、金額とトランザクションハッシュはそのまま保持しています。新しい X402 注文では支払い方法の割引は適用されません。今回の 402 レスポンスの amount を署名および支払いの根拠としてください。
結果の説明:
  • 注文の作成に成功すると、状態は Pending となり、この時点ではまだオンチェーン支払いは行われていません。
  • 最初の pay/ リクエストには PAYMENT-SIGNATURE が含まれていないため、HTTP 402 が返されます。
  • accepts は Base exact と Solana exact の両方を提示しており、このチュートリアルでは以降 Base を選択します。
  • 注文作成時の価格は 1.26 であり、旧 X402 支払い割引ポリシー期間中に支払われたため、実際の署名および決済金額は 1.2 USDC、すなわち 1200000 atomic USDC です。
ここでの resource はサーバー側から返され、署名にも関与するフィールドです。クライアント側で、その中のプロトコル、パス、または注文 ID を自分で書き換えないでください。

署名して再試行する

注文支払いでは、@acedatacloud/x402-client または acedatacloud-x402 の低レベル署名関数を再利用できます。以下は TypeScript の例です:
同じ注文に対して Base exact で署名し、再試行した後のプログラム実行結果:
オンチェーン確認結果:
結果の説明:
  • status 200 は、プラットフォームの注文支払いインターフェースがこの PAYMENT-SIGNATURE を受け付けたことを示します。
  • has_x_payment_response True は、レスポンスヘッダーに Base64 エンコードされた PAYMENT-RESPONSE レシートが含まれていることを示します。
  • settle_header.success=True かつ network=base は、Facilitator が Base settlement を完了したことを示します。
  • 注文の最終ステータスは Finished、pay_way は X402、pay_id にはオンチェーン取引ハッシュが書き込まれます。
  • BaseScan 上の Transfer イベントは、支払いアドレスがプラットフォームの受取アドレスへ 1200000 atomic USDC、すなわち 1.2 USDC を送金したことを示します。

成功レスポンスとレシート

注文の支払いが成功すると、レスポンスボディは注文情報です。プラットフォームはレスポンスヘッダー PAYMENT-RESPONSE に Base64 エンコードされた settlement response も含めます。デコード後の一般的なフィールドは以下のとおりです: 照合が必要な場合は、注文 ID、支払いウォレットアドレス、transaction、および注文の最終ステータスを同時に保存することを推奨します。

注意事項

  • 注文の支払いにはプラットフォームのアカウントトークンが必要であり、X402 ウォレット署名だけでは完了できません。
  • amount は USDC atomic units を使用し、1200000 は 1.2 USDC を表します。
  • 受取アドレスや資産アドレスを自分で組み立てず、402 レスポンス内の accepts を基準にしてください。
  • 同じ PAYMENT-SIGNATURE が繰り返し送信された場合、Facilitator は nonce によるリプレイ保護を行います。

支払い失敗レスポンス

PAYMENT-SIGNATURE を伴わない最初の HTTP 402 は通常の支払いチャレンジであり、支払い失敗を意味するものではありません。署名後の検証または決済に失敗した場合も、互換性のために標準の文字列 error を残し、extensions.acedatacloud.paymentError で安定したエラー構造を返します:
クライアントは code に基づくローカライズを優先し、不明な code は汎用的な支払い失敗にフォールバックする必要があります。charged は三値フィールドです。決済前に明確に拒否された場合にのみ false が返されます。フィールドが欠落している場合は、請求状態が不明であることを示し、「請求されていない」と解釈することはできません。現在、注文が Failed になった後は同じ注文を再試行できません。ウォレットの問題を修正した後、新しい注文を作成してください。 完全な PAYMENT-SIGNATURE、ウォレット署名、認可 payload、Facilitator の生診断情報、または RPC レスポンスを記録または送信しないでください。カスタマーサポートの調査には、注文 ID と公開されたエラー code だけが必要です。