أداة اختبار Webhook

اختبر Webhookتحقق من التوقيع

عدّل نصًا تجريبيًا وأنشئ توقيع HMAC-SHA256 وطلب cURL للتحقق من منطق الاستقبال في بيئة الاختبار.

مساحة توقيع Webhook

اضبط الاختبار، وعدّل النص، وانسخ التوقيع والطلب.

01

إعداد الاختبار

أدخل العنوان ومفتاح الاختبار والطابع الزمني.

يُحسب التوقيع في المتصفح. استخدم مفتاحًا تجريبيًا.

طابع Unix بالمللي ثانية، كما في ترويسات BoltUtil.

02

تعديل النص وإنشاء التوقيع

يُحدّث التوقيع وcURL عند تعديل JSON.

التوقيع

HMAC-SHA256

أدخل مفتاحًا وطابعًا زمنيًا وJSON صالحًا.

يُحسب من الطابع الزمني والنص الأصلي ومفتاح الاختبار.

JSON صالح
cURL / POSTطلب تجريبي
أدخل عنوانًا ومفتاحًا وطابعًا زمنيًا وJSON صالحًا.

مثال لإشعار طلب USDC ويمكن تغييره إلى USDT. الطلب والعناوين ومعرّف المعاملة أمثلة وليست إثباتًا للدفع.

لا ترسل الأداة طلبات تلقائيًا. شغّل cURL يدويًا في بيئة الاختبار.

تحقق قبل المتابعة

تحقق بالقاعدة نفسها، واحفظ الحدث ثم حدّث الطلب.

دليل التحقق من التوقيع
HMAC_SHA256(timestamp + "." + rawBody, secret)
  1. 01

    التحقق من الجسم الخام

    استخدم الطابع الزمني بالمللي ثانية من الرأس والنص الأولي الدقيق لحساب HMAC قبل تحليل JSON. تؤثر المسافات البيضاء وفواصل الأسطر وترتيب الحقول على التوقيع.

  2. 02

    استخدم التوقيت الآمن للمقارنة

    قارن التوقيع المستلم مع مساعد ثابت الوقت يوفره وقت تشغيل لغتك.

  3. 03

    قم بالتسجيل بأمان، ثم قم بإرجاع 2xx

    لا يتم إرجاع النجاح إلا بعد تسجيل الحدث أو وضعه في قائمة انتظار داخلية متينة.

غير متطابقة؟ ابدأ هنا

تحقق من النص الأصلي والسر وحالة الاستجابة لتحديد المشكلة.

01

عدم تطابق التوقيع

السبب الأكثر شيوعًا هو توقيع JSON الذي تم تحليله بدلاً من النص الأولي الدقيق، أو استخدام طابع زمني مختلف عن رأس الطلب.

02

سر خاطئ

استخدم سر الرد التلقائي على الويب الذي تم تكوينه لنقطة نهاية التاجر. يجب التعامل مع مفاتيح واجهة برمجة التطبيقات (API) وأسرار خطاف الويب كبيانات اعتماد مختلفة.

03

قام المحلل اللغوي بتغيير الحمولة

يمكن للبرامج الوسيطة JSON إعادة ترتيب الحمولات أو إعادة تنسيقها. التقط النص الخام قبل التحليل عند التحقق من توقيعات HMAC.

04

تقوم نقطة النهاية بإرجاع غير 2xx

الاستجابة خارج 2xx تعني فشل التسليم. إعادة المحاولة تعتمد على نوع الإشعار وحالة HTTP والسياسة.

05

المعالجة ليست عاجزة

أزل التكرار بمعرّف الطلب والحالة أو معرّف حدث فريد. قد تحتوي المعاملة على عدة تحويلات.

06

النجاح قبل الاستمرارية

قم بإرجاع HTTP 2xx فقط بعد كتابة الحدث إلى قاعدة البيانات أو قائمة الانتظار الخاصة بك. وإلا فقد يؤدي حدوث عطل إلى فقدان إشعار الدفع المكتمل.

أسئلة أثناء التصحيح

التحقق من التوقيع، والردود، وعمليات التسليم المكررة.

لماذا يفشل التحقق من توقيع webhook الخاص بي؟

تحقق من نص الطلب الأولي الدقيق ورأس الطابع الزمني وسر خطاف الويب الذي تم تكوينه. عادةً ما يؤدي توقيع JSON الذي تم تحليله أو الجسم المعاد تنسيقه إلى إنتاج HMAC مختلف.

هل يجب أن تعيد نقطة نهاية خطاف الويب الخاص بي النجاح في نص الاستجابة؟

لا. يعتمد BoltUtil على حالة HTTP؛ تعني 2xx نجاح الاستلام. تحقق من الحدث واحفظه أولًا.

كيف يمكنني التعامل مع عمليات تسليم webhook المكررة؟

استخدم قيدًا فريدًا أو عملية ذرية بمعرّف الطلب والحالة أو الحدث. معرّف المعاملة وحده لا يكفي.

متى يجب أن ترجع نقطة النهاية الخاصة بي HTTP 2xx؟

أعد 2xx بعد التحقق والحفظ. عند الفشل أعد خطأ مناسبًا؛ إعادة المحاولة تعتمد على النوع والسياسة.