PAYMENT-SIGNATURE، ثم يعيد المحاولة بالطلب نفسه.
الفرق هو أن دفع الطلبات ينتمي إلى منصة API ويتطلب رمز حساب؛ بينما يمكن لـ AI API الذي يستدعي x402.acedata.cloud مباشرةً استخدام X402 فقط، دون الحاجة إلى API Token.
تجهيز الطلب
ادخل إلى وحدة تحكم Ace Data Cloud، واختر الطلب المطلوب دفعه، وسجّل معرّف الطلب. إذا لم يكن لديك طلب بعد، يمكنك إنشاء طلب بانتظار الدفع في صفحة الباقات. يعتمد سعر الطلب على ما هو معروض في الصفحة، ويمثلamount في استجابة X402 402 الأساس النهائي للتوقيع.
إنشاء رمز الحساب
يتطلب طلب دفع الطلب رمز حساب. افتح صفحة Platform Token، وأنشئ token بتنسيقplatform-v1-....
تستخدم الطلبات اللاحقة:
تشغيل 402
أرسل أولًا طلبًا دونPAYMENT-SIGNATURE:
accepts:
x402Version هي 2، ويستخدم network معرّف CAIP-2، وحقل المبلغ هو amount.
نتيجة تشغيل البرنامج لإنشاء طلب 10 Credits وتشغيل 402:
سجلات المعاملات التالية عينات تاريخية تم اختبارها فعليًا بموجب السياسة القديمة، مع الاحتفاظ بالمبالغ وتجزئات المعاملات كما هي. لم تعد طلبات X402 الجديدة تتضمن خصومات لطريقة الدفع؛ يرجى اعتماد amount في استجابة 402 هذه كأساس للتوقيع والدفع.
- بعد إنشاء الطلب بنجاح، تكون حالته
Pending، ولا يوجد دفع على السلسلة في هذه المرحلة. - لم يتضمن طلب
pay/الأولPAYMENT-SIGNATURE، لذا أعاد HTTP 402. - يوفر
acceptsكلًا من BaseexactوSolanaexact، ويختار هذا الدليل Base لاحقًا. - كان سعر الطلب عند إنشائه
1.26، وخلال سياسة خصم الدفع القديمة عبر X402، كان مبلغ التوقيع والتسوية الفعلي هو1.2USDC، الموافق لـ1200000atomic USDC.
resource هنا حقل يعيده الخادم ويشارك في التوقيع، ويجب على العميل عدم إعادة كتابة البروتوكول أو المسار أو معرّف الطلب الموجود فيه بنفسه.
التوقيع وإعادة المحاولة
يمكن لدفع الطلبات إعادة استخدام دوال التوقيع منخفضة المستوى في@acedatacloud/x402-client أو acedatacloud-x402. فيما يلي مثال TypeScript:
exact وإعادة المحاولة:
- يشير
status 200إلى أن واجهة دفع الطلبات في المنصة قبلتPAYMENT-SIGNATUREهذه. - يشير
has_x_payment_response Trueإلى أن رأس الاستجابة يتضمن إيصالPAYMENT-RESPONSEمُرمّزًا بـ Base64. - يشير
settle_header.success=Trueوnetwork=baseإلى أن الـ Facilitator أكمل تسوية Base. - الحالة النهائية للطلب هي
Finished، وpay_wayهوX402، وpay_idيحتوي على تجزئة معاملة السلسلة. - يُظهر حدث
Transferعلى BaseScan أن عنوان الدفع حوّل1200000USDC atomic إلى عنوان استلام المنصة، أي1.2USDC.
الاستجابة الناجحة والإيصال
بعد نجاح دفع الطلب، يكون جسم الاستجابة هو معلومات الطلب. كما تحمل المنصة في رأس الاستجابةPAYMENT-RESPONSE استجابة تسوية مُرمّزة بـ Base64، وتشمل الحقول الشائعة بعد فك الترميز:
إذا كنت بحاجة إلى المطابقة، يُنصح بحفظ معرّف الطلب وعنوان محفظة الدافع و
transaction والحالة النهائية للطلب في الوقت نفسه.
ملاحظات
- يتطلب دفع الطلب رمز حساب المنصة، ولا يمكن إتمامه بالاعتماد على توقيع محفظة X402 فقط.
- يستخدم
amountوحدات USDC atomic، ويمثل1200000قيمة1.2USDC. - لا تُنشئ عنوان الاستلام أو عنوان الأصل بنفسك، واعتمد على
acceptsفي استجابة 402. - إذا تم إرسال
PAYMENT-SIGNATUREنفسها بشكل متكرر، فسيطبق الـ Facilitator حماية من إعادة التشغيل وفقًا لـ nonce.
استجابة فشل الدفع
إن أول HTTP 402 دون تضمينPAYMENT-SIGNATURE هو تحدي دفع طبيعي، ولا يعني فشل الدفع. لا يزال فشل التحقق أو التسوية بعد التوقيع يحتفظ بالسلسلة القياسية error كآلية توافق احتياطية، ويعيد بنية خطأ مستقرة في extensions.acedatacloud.paymentError:
code، والرجوع إلى فشل الدفع العام عند وجود code غير معروف. charged حقل ثلاثي الحالات: لا يعيد false إلا عند الرفض الصريح قبل التسوية؛ ويعني غياب الحقل أن حالة الخصم غير معروفة، ولا يمكن تفسيره على أنه «لم يتم الخصم». بعد دخول الطلب الحالي إلى Failed، لا يمكن إعادة محاولة الطلب الأصلي؛ يُرجى إنشاء طلب جديد بعد إصلاح مشكلة المحفظة.
لا تسجل أو ترسل PAYMENT-SIGNATURE الكامل أو توقيع المحفظة أو payload التفويض أو تشخيصات الـ Facilitator الأولية أو استجابات RPC. لا يحتاج فحص دعم العملاء إلا إلى معرّف الطلب وcode الخطأ العام.
