PAYMENT-SIGNATURE に署名してから、同じリクエストで再試行します。
違いは、注文支払いはアカウントトークンを必要とするプラットフォーム API であることです。一方、x402.acedata.cloud の AI API を直接呼び出す場合は、X402 のみを使用でき、API Token は不要です。
注文を準備する
Ace Data Cloud コンソールにアクセスし、支払いが必要な注文を選択して、注文 ID を記録します。 まだ注文がない場合は、プランページで未払い注文を作成できます。注文価格はページに表示される内容に従い、X402 の 402 レスポンス内のamount が最終的な署名根拠となります。
アカウントトークンを作成する
注文支払いリクエストにはアカウントトークンが必要です。プラットフォーム Token ページを開き、platform-v1-... 形式の token を作成します。
以降のリクエストでは以下を使用します:
402 をトリガーする
まず、PAYMENT-SIGNATURE を付けずにリクエストを 1 回送信します:
accepts が含まれます:
x402Version は 2、network は CAIP-2 識別子を使用し、金額フィールドは amount です。
10 Credits の注文を作成して 402 をトリガーしたプログラム実行結果:
以下の取引記録は旧ポリシー下における過去の実測サンプルであり、金額とトランザクションハッシュはそのまま保持しています。新しい X402 注文では支払い方法の割引は適用されません。今回の 402 レスポンスの amount を署名および支払いの根拠としてください。
- 注文の作成に成功すると、状態は
Pendingとなり、この時点ではまだオンチェーン支払いは行われていません。 - 最初の
pay/リクエストにはPAYMENT-SIGNATUREが含まれていないため、HTTP 402 が返されます。 acceptsは Baseexactと Solanaexactの両方を提示しており、このチュートリアルでは以降 Base を選択します。- 注文作成時の価格は
1.26であり、旧 X402 支払い割引ポリシー期間中に支払われたため、実際の署名および決済金額は1.2USDC、すなわち1200000atomic USDC です。
resource はサーバー側から返され、署名にも関与するフィールドです。クライアント側で、その中のプロトコル、パス、または注文 ID を自分で書き換えないでください。
署名して再試行する
注文支払いでは、@acedatacloud/x402-client または acedatacloud-x402 の低レベル署名関数を再利用できます。以下は TypeScript の例です:
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イベントは、支払いアドレスがプラットフォームの受取アドレスへ1200000atomic USDC、すなわち1.2USDC を送金したことを示します。
成功レスポンスとレシート
注文の支払いが成功すると、レスポンスボディは注文情報です。プラットフォームはレスポンスヘッダーPAYMENT-RESPONSE に Base64 エンコードされた settlement response も含めます。デコード後の一般的なフィールドは以下のとおりです:
照合が必要な場合は、注文 ID、支払いウォレットアドレス、
transaction、および注文の最終ステータスを同時に保存することを推奨します。
注意事項
- 注文の支払いにはプラットフォームのアカウントトークンが必要であり、X402 ウォレット署名だけでは完了できません。
amountは USDC atomic units を使用し、1200000は1.2USDC を表します。- 受取アドレスや資産アドレスを自分で組み立てず、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 だけが必要です。
