Skip to main content
بالإضافة إلى الدفع مباشرةً وفق طلبات API، تدعم Ace Data Cloud أيضًا دفع طلبات وحدة تحكم X402. البروتوكول الأساسي لدفع الطلبات واستدعاءات API متماثل: يعيد الطلب الأول 402، ويوقّع العميل PAYMENT-SIGNATURE، ثم يعيد المحاولة بالطلب نفسه. الفرق هو أن دفع الطلبات ينتمي إلى منصة API ويتطلب رمز حساب؛ بينما يمكن لـ AI API الذي يستدعي x402.acedata.cloud مباشرةً استخدام X402 فقط، دون الحاجة إلى API Token.

تجهيز الطلب

ادخل إلى وحدة تحكم Ace Data Cloud، واختر الطلب المطلوب دفعه، وسجّل معرّف الطلب. إذا لم يكن لديك طلب بعد، يمكنك إنشاء طلب بانتظار الدفع في صفحة الباقات. يعتمد سعر الطلب على ما هو معروض في الصفحة، ويمثل amount في استجابة X402 402 الأساس النهائي للتوقيع.

إنشاء رمز الحساب

يتطلب طلب دفع الطلب رمز حساب. افتح صفحة Platform Token، وأنشئ token بتنسيق platform-v1-.... تستخدم الطلبات اللاحقة:
يختلف رمز الحساب عن API Token العادي. يُستخدم API Token العادي لاستهلاك حصة API؛ بينما يُستخدم رمز الحساب لتمثيل حسابك في تشغيل موارد المنصة، مثل دفع الطلبات.

تشغيل 402

أرسل أولًا طلبًا دون PAYMENT-SIGNATURE:
تكون حالة الإرجاع 402، وتتضمن الاستجابة accepts:
يستخدم دفع الطلبات بروتوكول x402 v2 الرسمي: تكون قيمة x402Version هي 2، ويستخدم network معرّف CAIP-2، وحقل المبلغ هو amount. نتيجة تشغيل البرنامج لإنشاء طلب 10 Credits وتشغيل 402:
سجلات المعاملات التالية عينات تاريخية تم اختبارها فعليًا بموجب السياسة القديمة، مع الاحتفاظ بالمبالغ وتجزئات المعاملات كما هي. لم تعد طلبات X402 الجديدة تتضمن خصومات لطريقة الدفع؛ يرجى اعتماد amount في استجابة 402 هذه كأساس للتوقيع والدفع.
توضيح النتائج:
  • بعد إنشاء الطلب بنجاح، تكون حالته Pending، ولا يوجد دفع على السلسلة في هذه المرحلة.
  • لم يتضمن طلب pay/ الأول PAYMENT-SIGNATURE، لذا أعاد HTTP 402.
  • يوفر accepts كلًا من Base exact وSolana exact، ويختار هذا الدليل Base لاحقًا.
  • كان سعر الطلب عند إنشائه 1.26، وخلال سياسة خصم الدفع القديمة عبر X402، كان مبلغ التوقيع والتسوية الفعلي هو 1.2 USDC، الموافق لـ 1200000 atomic USDC.
لاحظ أن resource هنا حقل يعيده الخادم ويشارك في التوقيع، ويجب على العميل عدم إعادة كتابة البروتوكول أو المسار أو معرّف الطلب الموجود فيه بنفسه.

التوقيع وإعادة المحاولة

يمكن لدفع الطلبات إعادة استخدام دوال التوقيع منخفضة المستوى في @acedatacloud/x402-client أو acedatacloud-x402. فيما يلي مثال TypeScript:
نتيجة تشغيل البرنامج بعد توقيع الطلب نفسه باستخدام Base 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 أن عنوان الدفع حوّل 1200000 USDC atomic إلى عنوان استلام المنصة، أي 1.2 USDC.

الاستجابة الناجحة والإيصال

بعد نجاح دفع الطلب، يكون جسم الاستجابة هو معلومات الطلب. كما تحمل المنصة في رأس الاستجابة PAYMENT-RESPONSE استجابة تسوية مُرمّزة بـ Base64، وتشمل الحقول الشائعة بعد فك الترميز: إذا كنت بحاجة إلى المطابقة، يُنصح بحفظ معرّف الطلب وعنوان محفظة الدافع وtransaction والحالة النهائية للطلب في الوقت نفسه.

ملاحظات

  • يتطلب دفع الطلب رمز حساب المنصة، ولا يمكن إتمامه بالاعتماد على توقيع محفظة X402 فقط.
  • يستخدم amount وحدات USDC atomic، ويمثل 1200000 قيمة 1.2 USDC.
  • لا تُنشئ عنوان الاستلام أو عنوان الأصل بنفسك، واعتمد على 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 الخطأ العام.