Skip to main content
X402 هو بروتوكول دفع على السلسلة “محاسبة HTTP 402” اقترحته Coinbase: يقوم الخادم بإرجاع 402 Payment Required على الطلبات التي لا تحتوي على توكن، مع حقل accepts: [...] الذي يسرد السلاسل / الأصول / الأسعار المقبولة؛ يقوم العميل بتوقيع تفويض محلي (على EVM هو Permit2 / EIP-712، على Solana هو تفويض نقل توكن SPL)، ثم يضع الحزمة المشفرة بـ base64 في رأس PAYMENT-SIGNATURE ويعيد إرسال الطلب. بعد التحقق من قبل الخادم، يتم التسوية فعليًا على السلسلة، ثم يتم إرجاع نتيجة العمل.
يقوم عميل X402 الخاص بـ Ace Data Cloud باستدعاء API المستهدف مباشرة، ويستخدم 402 Payment Required و accepts التي تم إرجاعها في الوقت الفعلي كمرجع للسعر والتوقيع. يمكن التحقق من قدرة الدفع لـ Facilitator في /.well-known/x402.
@acedatacloud/sdk و acedatacloud كلاهما يكشف عن هوك paymentHandler: عندما يتلقى الطلب الذي أرسله SDK نفسه 402، يتم استدعاء المعالج الذي قمت بحقنه للحصول على رأس PAYMENT-SIGNATURE، ثم يعيد إرسال الطلب الأصلي. باستخدام @acedatacloud/x402-client / acedatacloud-x402 مع SDK، تكون العملية بأكملها شفافة تمامًا لرمز العمل - عليك فقط استخدام client.openai.chat.completions.create(...)، يبدو وكأنه نموذج توكن تمامًا، لكن في الأساس يتم الدفع حسب الاستخدام، ولا حاجة لإعادة الشحن مسبقًا. المقال:
  • تم توصيل سلسلة “بدون توكن + حقن X402 handler” على جانب TS ( تحقق T12 )
  • تم سرد الفروق بين سلسلتي التوقيع EVM / Solana
  • تم تقديم ثلاثة أنماط تكيف: نمط مفتاح خاص viem، نمط محفظة المتصفح، نمط Python EVMAccountSigner
  • تم توضيح الحقل preferScheme / prefer_scheme الذي قد يكون من السهل الوقوع فيه

أولاً، نظرة عامة على البروتوكول (يجب قراءته)

يتضمن استدعاء X402 الناجح 3 جولات HTTP RTT:
حزمة X402 هي جزء من JSON، يتم تشفيرها بـ base64 ثم توضع في رأس PAYMENT-SIGNATURE. الهيكل (مقتطف):
الطبقة العليا من الحزمة هي x402Version: 2، وتستخدم كائن accepted للإعلان عن scheme و network المختارين في هذه المرة (تحديد CAIP-2). يستخدم preferScheme / prefer_scheme لاختيار التفضيل عندما يقدم الخادم أنواع متعددة من المخططات في نفس الوقت. إذا كان الخادم يعرض فقط exact، سيتم تجاهل هذا الحقل؛ إذا تم تعيين upto ولكن الخادم لم يعرضه، سيتم التراجع إلى أول عنصر مطابق.

ثانياً، TypeScript: محفظة المتصفح + خادم viem طريقتان للاستخدام

التثبيت

أرقام الإصدارات التي تم اختبارها:

createX402PaymentHandler التوقيع الكامل

قيمة الإرجاع هي (ctx) => Promise&lt;{ headers: Record<string, string> }>، تتطابق تمامًا مع توقيع هوك paymentHandler الخاص بـ SDK.

الاستخدام 1: المتصفح (MetaMask / WalletConnect)

عند الاستدعاء الأول، ستظهر للمستخدم مرتين نافذة توقيع: الأولى هي تفويض Permit2 لـ USDC (المبلغ هو MaxUint256، مكتوب على السلسلة)؛ الثانية هي توقيع حزمة X402 لـ EIP-712 (لا تذهب إلى السلسلة، فقط للتحقق من facilitator). الاستدعاءات اللاحقة تحتاج فقط إلى التوقيع الثاني، مما يجعل التجربة “نقرة واحدة للتوقيع → الحصول على النتيجة”.

الاستخدام 2: خادم Node + مفتاح خاص viem (مناسب للخلفية / CLI)

@acedatacloud/x402-client في جانب TS يقبل فقط مزود EIP-1193 - إنه لا يدير المفاتيح الخاصة مباشرة. في سيناريو Node / CLI، الطريقة القياسية هي استخدام viem لتغليف المفتاح الخاص في WalletClient، ثم استخدام @ethereumjs/util أو التكيف الداخلي لـ viem مع EIP-1193.
إذا كنت تعتقد أن توافق EIP-1193 في viem غير مستقر بما فيه الكفاية، يمكنك استخدام signEVMUptoPayment في مستوى أدنى، حيث تقوم بربط accepts → signed envelope → PAYMENT-SIGNATURE header بنفسك، متجاوزًا خطافات SDK؛ ومع ذلك، يُوصى بالاستمرار في استخدام createX402PaymentHandler لتجنب الحاجة إلى صيانة ترقية البروتوكول بنفسك.

الاستخدام 3: سولانا

سلسلة سولانا حاليًا تظهر فقط exact scheme، لذا فإن preferScheme لا يعمل على سولانا.

ثالثًا، بايثون: وضع المفتاح الخاص

تستخدم بايثون acedatacloud-x402 توقيع المفتاح الخاص مباشرة (بدون تجريد EIP-1193)، مما يجعلها أكثر ملاءمة للخوادم / منفذي المهام.

التثبيت

الإصدار الذي تم اختباره:

EVM (Base / Skale)

سولانا

الموافقة لمرة واحدة (فقط EVM في المرة الأولى)

على EVM Base، يسير X402 عبر Permit2، مما يتطلب من المحفظة الموافقة على USDC لعقد Permit2 مرة واحدة باستخدام MaxUint256. يحتوي acedatacloud-x402 على approve_permit2 مدمج:
تحتاج هذه المعاملة إلى الإرسال مرة واحدة فقط، وبعد ذلك ستستخدم جميع مدفوعات X402 EVM هذه التفويض. لا تحتاج سولانا إلى ذلك.

رابعًا، التحقق من التشغيل الحقيقي

هدف الاختبار: SDK TS لا يمرر الرمز، حقن معالج X402، يمكنه بناء وإطلاق الطلب بشكل طبيعي (تحقق خفيف لا يستهلك USDC الحقيقي على السلسلة).
الإخراج:
نتيجة الشرح:
  • لم يتم تمرير apiToken، بناء SDK لا يثير خطأ، مما يثبت أن وضع X402 هو بديل قانوني للرمز.
  • createX402PaymentHandler تعيد دالة (خطاف)، يحصل SDK عليها فقط عند استلام 402.
  • اختبار شامل للدفع على السلسلة، نظرًا لأنه يتضمن خصم USDC الحقيقي، لم يتم تضمينه في هذا الدليل؛ يمكنك الرجوع إلى دليل تكامل X402 للحصول على أمثلة e2e.
جانب بايثون create_x402_payment_handler قام أيضًا بنفس التحقق - قيمة الإرجاع هي callable، وعند حقن payment_handler=...، لا يثير AceDataCloud(...) خطأ. تتماشى المعاني على الجانبين.

خامسًا، مقارنة مع “وضع رمز Bearer”

六、常见陷阱

  1. chat 类必须 preferScheme=upto:用 exact 会让 facilitator 按 maxAmountRequired(不是实际用量)扣 USDC。
  2. Node 端别传裸私钥给 createX402PaymentHandler:TS 包不接受 { privateKey },必须包成 EIP-1193 provider(推荐 viem WalletClient)。
  3. 首次调用是双签名:第一次签 Permit2 approve(上链、有 gas),第二次签 X402 envelope(不上链)。后续调用只剩第二次。
  4. Solana 没有 Permit2 概念:直接签 SPL token transfer 授权,不需要 approve;但目前 Solana 链上只支持 exact。
  5. 业务报错和支付错误区分:402 → handler 失败抛 X402SignError(具体类型按链不同);后续重发后业务接口的报错(401 / 422 / 5xx)仍然按普通 SDK 异常分类。
  6. viem 适配最稳的写法:evmProvider: walletClient as any 会失去类型检查但兼容性最好;如果想保留类型,用 viem 的 .transport.request 单独包一层 { request } 对象传进去。

了解更多