هل تطلب نقطة النهاية الخاصة بك للمدفوعات «بطريقة صحيحة» حقًّا؟ أدخل عنوان URL لنقطة النهاية، وسيتم التحقق من البنود التالية واحدة تلو الأخرى: هل تُرجع رمز الحالة 402 عند عدم الدفع؟ وهل تتضمن رأس payment-required؟ وهل الشبكة هي شبكة Base الرئيسية؟ وهل عنوان المستلم والمبلغ صحيحان؟ وهل يمكن للمتصفح قراءة الرؤوس المخصصة؟ وهل زمن الاستجابة سريعٌ أم بطيءٌ؟ وبعد الانتهاء من الفحص، ستحصل مباشرةً على كود Node.js / Express جاهز للنسخ والاستخدام.
أرسل طلبًا واحدًا مباشرةً من متصفحك. وإذا لم يكن لدى الطرف الآخر تمكين CORS، فسيمنع المتصفح الطلب — وفي هذه الحالة، استخدم الطريقة B أدناه.
شغّل أمر curl المولَّد أدناه على الخادم، ثم الصق المخرجات الكاملة هنا — وهذه الطريقة غير خاضعة لقيود CORS، وأدق في النتائج.
يتم إنشاؤه تلقائيًا بعد ملء عنوان URL للنهاية.
يتم إنشاؤه تلقائيًا بعد ملء عنوان URL للنهاية.
نقطة النهاية التي تُرجع SSE تم تصنيفها على أنها "ميتة".يستخدم مكتشف الحالة الخاص بنا عميل JSON-RPC لاختبار نقاط النهاية MCP، ويُرجع الطرف الآخر تدفق SSE بدلًا من JSON، وبالتالي يُعتبر النقطة معطلة عند فشل التحليل. وبعد ذلك تم تعديله إلىالنظر فقط في رموز حالة HTTP، وكلٌّ من 200 و402 يُعدان مؤشرًا على أن الخدمة تعمل.
2 · لا يمكن للمتصفح قراءة رؤوس الاستجابة المخصصة.تحت CORS، يمكن قراءة رؤوس الاستجابة البسيطة فقط،payment-required يجب إدخاله Access-Control-Expose-Headers، وإلا فإن الواجهة الأمامية تتلقى قيمة null.
3 · وُضع وحدة المبلغ بشكل خاطئ.USDC يحتوي على 6 أرقام عشرية،maxAmountRequired اكتب بأصغر وحدة: 0.01 USDC = 10000مكتوب كـ 0.01 المبلغ المُستَلم فعليًّا هو 0.00000001 دولار أمريكي فقط.
4 · وكيل محلي يُحدث إنذارات كاذبة.يجب دائمًا إضافة التحقق من حالة تشغيل الموقع. --noproxy '*'، كنا نخطئ في تفسير رمز الحالة 410 المرتجع من البروكسي على أنه "نطاق الجذر معطل"، بينما كان الرمز الفعلي هو 200.