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، نمط محفظة المتصفح، نمط PythonEVMAccountSigner - تم توضيح الحقل
preferScheme/prefer_schemeالذي قد يكون من السهل الوقوع فيه
أولاً، نظرة عامة على البروتوكول (يجب قراءته)
يتضمن استدعاء X402 الناجح 3 جولات HTTP RTT:PAYMENT-SIGNATURE. الهيكل (مقتطف):
x402Version: 2، وتستخدم كائن accepted للإعلان عن scheme و network المختارين في هذه المرة (تحديد CAIP-2).
يستخدم
preferScheme / prefer_scheme لاختيار التفضيل عندما يقدم الخادم أنواع متعددة من المخططات في نفس الوقت. إذا كان الخادم يعرض فقط exact، سيتم تجاهل هذا الحقل؛ إذا تم تعيين upto ولكن الخادم لم يعرضه، سيتم التراجع إلى أول عنصر مطابق.
ثانياً، TypeScript: محفظة المتصفح + خادم viem طريقتان للاستخدام
التثبيت
createX402PaymentHandler التوقيع الكامل
(ctx) => Promise<{ headers: Record<string, string> }>، تتطابق تمامًا مع توقيع هوك paymentHandler الخاص بـ SDK.
الاستخدام 1: المتصفح (MetaMask / WalletConnect)
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 مدمج:
رابعًا، التحقق من التشغيل الحقيقي
هدف الاختبار: SDK TS لا يمرر الرمز، حقن معالج X402، يمكنه بناء وإطلاق الطلب بشكل طبيعي (تحقق خفيف لا يستهلك USDC الحقيقي على السلسلة).- لم يتم تمرير
apiToken، بناء SDK لا يثير خطأ، مما يثبت أن وضع X402 هو بديل قانوني للرمز. createX402PaymentHandlerتعيد دالة (خطاف)، يحصل SDK عليها فقط عند استلام 402.- اختبار شامل للدفع على السلسلة، نظرًا لأنه يتضمن خصم USDC الحقيقي، لم يتم تضمينه في هذا الدليل؛ يمكنك الرجوع إلى دليل تكامل X402 للحصول على أمثلة e2e.
جانب بايثونcreate_x402_payment_handlerقام أيضًا بنفس التحقق - قيمة الإرجاع هي callable، وعند حقنpayment_handler=...، لا يثيرAceDataCloud(...)خطأ. تتماشى المعاني على الجانبين.
خامسًا، مقارنة مع “وضع رمز Bearer”
六、常见陷阱
- chat 类必须
preferScheme=upto:用exact会让 facilitator 按maxAmountRequired(不是实际用量)扣 USDC。 - Node 端别传裸私钥给
createX402PaymentHandler:TS 包不接受{ privateKey },必须包成 EIP-1193 provider(推荐 viemWalletClient)。 - 首次调用是双签名:第一次签 Permit2 approve(上链、有 gas),第二次签 X402 envelope(不上链)。后续调用只剩第二次。
- Solana 没有 Permit2 概念:直接签 SPL token transfer 授权,不需要 approve;但目前 Solana 链上只支持
exact。 - 业务报错和支付错误区分:402 → handler 失败抛
X402SignError(具体类型按链不同);后续重发后业务接口的报错(401 / 422 / 5xx)仍然按普通 SDK 异常分类。 viem适配最稳的写法:evmProvider: walletClient as any会失去类型检查但兼容性最好;如果想保留类型,用 viem 的.transport.request单独包一层{ request }对象传进去。

