ابدأ من تبويب Deliveries: إن لم تحاول Didit الإرسال فالمشكلة في الاشتراك أو الوجهة، وإن فشلت فرمز الاستجابة يوضح السبب، و404 تعني أن مسارك غير قابل للوصول.
ابدأ من تبويب Deliveries الخاص بالوجهة. إذا لم تحاول Didit إرسال التسليم إطلاقًا، فالمشكلة في الاشتراك أو الوجهة. إذا حاولت وفشلت، يخبرك رمز الاستجابة أيهما: 404 تعني أن مسارك لم يكن قابلًا للوصول عند ذلك الرابط، وعدم تطابق التوقيع يعني أنك جزّأت (hash) بايتات خاطئة.
#الخطوة 1: هل حاولت Didit إرسال التسليم؟
افتح المطورون ثم Webhooks. اختر نقطة النهاية وافتح التسليمات لرؤية الطلب والاستجابة لكل محاولة. استخدم إعادة الإرسال بعد إصلاح الخلل. افحص التطبيق والبيئة والاشتراك في الأحداث، وتأكد أن نقطة النهاية ليست معطّلة.
هذا الفحص الواحد يقسم المشكلة إلى نصفين:
- لا توجد محاولة مسجَّلة ← لم يُولَّد الحدث أبدًا لتلك الوجهة. انتقل إلى الخطوة 2.
- محاولة مسجَّلة، فشلت ← أرسلته Didit ورفضه جانبك أو لم يستقبله. انتقل إلى الخطوة 3.
- محاولة مسجَّلة، 2xx ← تم تسليمه بنجاح. المشكلة داخل المعالج لديك، لا في التسليم.
#الخطوة 2: لم تُسجَّل أي محاولة
بترتيب الاحتمال:
- الحدث غير مشترك فيه. لا يوجد رمز بدل عام (wildcard) - يجب إدراج كل عائلة أحداث صراحةً. والاسم غير الموجود (
session.status.updated،kyc.completed) لا يستقبل شيئًا دون تنبيه. تحقق من قائمة الأحداث. - تطبيق خاطئ. الوجهات تخص تطبيقًا معينًا. إذا كانت جلساتك تعمل ضمن تطبيق مختلف عن الوجهة، فلن يصلها أي حدث أبدًا. هذا هو السبب الأكثر شيوعًا عندما يبدو كل شيء مُعدًّا بشكل صحيح.
- لم يتغيّر شيء فعليًا. تُطلَق الأحداث عند التغيير. جلسة لم تتحرك، أو إعادة فحص AML مستمر لم يجد شيئًا فوق العتبة، تُنتج بشكل صحيح لا حدث.
- الحالة التي تنتظرها لم تحدث بعد. جلسة في حالة In Progress لم تنتهِ. انظر عندما لا تنتهي جلسة أبدًا.
#الخطوة 3: حاولت عملية التسليم وفشلت
خطأ 404 يعني أن الطلب وصل إلى شيء لا يملك مسارك. تحقق من:
- المسار الدقيق، بما في ذلك الشرطة المائلة الأخيرة. إطار عمل يعيد توجيه
/hookإلى/hook/يمكن أن يحوّل نقطة نهاية عاملة إلى 404 أو جسم مفقود. - ما إذا كان الرابط عامًا. مضيف محلي أو تجريبي غير قابل للوصول من الإنترنت يفشل بهذه الطريقة.
- ما إذا كان وكيل، أو موازن تحميل، أو موجِّه قائم على المسار أمام تطبيقك يرسل ذلك المسار إلى مكان آخر.
خطأ 5xx يعني أن المعالج لديك رمى استثناءً. سجّل الجسم الخام قبل تحليله لترى ما استقبله فعليًا.
انتهاء المهلة يعني أنك لم تستجب بسرعة كافية. أعد 2xx أولًا، ثم عالج بعد ذلك.
لا شيء إطلاقًا / رفض الاتصال يعني أن حافتك حجبته. تُسلِّم Didit من عنوان IP الثابت 18.203.201.92 بعميل مستخدم DiditWebhook/2.0. إذا كنت خلف Cloudflare أو جدار حماية بموقف رفض افتراضي، اسمح بذلك العنوان لاسم المضيف المستقبِل.
#الحالة الكلاسيكية: التسليم الآلي يعطي 404 لكن Resend يعمل
هذه تتكرر بما يكفي لتستحق اسمًا. يفشل التسليم الآلي بخطأ 404، ثم النقر على Resend لنفس الحدث ينجح.
هذا التوليف يعني أن الحمولة ونقطة نهايتك سليمتان كلاهما - إذن الفارق هو التوقيت أو المسار، لا المحتوى. تحقق من:
- نشر أو إعادة تشغيل في لحظة التسليم الأصلي. ينجح Resend لاحقًا لأن التطبيق يعمل مجددًا.
- بدء بارد تجاوز مهلة منصتك - شائع في serverless مع أول استدعاء بطيء.
- توجيه قائم على المسار تغيّر بين المحاولتين، أو قاعدة لا تطابق سوى بعض الطلبات.
- تحديد معدل أو حماية من الروبوتات على حافتك سمحت بمرور إعادة الإرسال اليدوية لأنها وصلت وحدها لا ضمن دفعة.
يحتوي تبويب Deliveries على كلتا المحاولتين بطوابعهما الزمنية - قارنهما بسجلات النشر والأخطاء لديك في تلك الدقيقة.
#فشل التحقق من التوقيع
يكاد يكون دائمًا واحدًا من ثلاثة أشياء:
- جزّأت JSON مُعاد التسلسل. جزّئ بـ HMAC بايتات الجسم الخام للطلب تمامًا كما وصلت. التحليل ثم إعادة التسلسل يغيّر المسافات وترتيب المفاتيح، ولن يتطابق التوقيع. تحتاج معظم أطر العمل إلى إعداد صريح لتمنحك الجسم الخام.
- السر الخاطئ. سر التوقيع لكل وجهة، وهو ليس مفتاح API الخاص بك. لوجهتين سرّان مختلفان.
- افتراض ترميز خاطئ. إذا لم تكن متأكدًا مما إذا كان السر يُستخدم كسلسلة حرفية أو يُفكّ ترميزه أولًا، لا تخمّن - اتبع مرجع التحقق من التوقيع بدقة، وسجّل الجسم الخام أثناء التصحيح حتى تتمكن من المقارنة.
لا "تُصلح" أبدًا عدم تطابق التوقيع بتخطي التحقق. نقطة نهاية webhook غير مُتحقَّق منها ستقبل موافقة مزوَّرة من أي شخص يعثر على الرابط، مما يحوّل اختصارًا في التصحيح إلى مسار للاستيلاء على الحساب.
#محاولتان ليستا طابورًا
عند استجابة الخادم برمز 5xx أو 404، يعيد Didit المحاولة مرتين، بعد نحو دقيقة ثم أربع دقائق. لا تُعاد تلقائيًا محاولة الاتصال الفاشل أو المهلة التي تتجاوز 5 ثوانٍ. استخدم إعادة الإرسال في التسليمات بعد إصلاح السبب؛ يظهر تنبيه إذا استمر الفشل.
ابنِ مسار تسوية: عند بدء التشغيل، استقصِ نقطة نهاية القرار عن أي جلسة لا تملك لها حالة نهائية. عامل webhooks كمسار سريع والاستقصاء كخط دفاع احتياطي.
#الاختبار دون تشغيل عمليات تحقق
يرسل إرسال حدث تجريبي في صفحة الوجهة حدثًا مكتمل التكوين من أيّ نوع تختاره - مقبول، مرفوض، قيد المراجعة، KYB، كيان، معاملة. استخدمه لإثبات أن نقطة نهايتك، وفحص التوقيع، والمعالج لديك تعمل قبل أن تعتمد عليها جلسة حقيقية.
sandbox هو النصف الآخر من هذا: تُصدر جلسة sandbox أحداث webhook حقيقية بـ "environment": "sandbox"، لذا يمكنك تجربة المسار كاملًا من طرف إلى طرف مجانًا. انظر الاختبار في sandbox.
ما زلت عالقًا؟ تحدث إلى إنسان.
أرفق معرّف مؤسستك ومعرّف الجلسة التي تسأل عنها.