لا ترسل Didit بريدًا إلكترونيًا عندما تتغير حالة عملية تحقق - أعدّ webhook حتى تعرف خلفيتك بذلك لحظة حدوثه، وتحقق من التوقيع قبل أن تثق به.

إجابة مختصرة

الـ webhook هو طلب HTTP ترسله Didit إلى رابطك عندما يتغيّر شيء ما. أضف وجهة تحت المطورون → Webhooks، واشترك في الأحداث التي تريدها - لا يوجد رمز بدل عام، أدرجها كلها - احفظ سر التوقيع، وتحقق من التوقيع قبل معالجة أي شيء.

لا ترسل Didit بريدًا إلكترونيًا لك عندما تنتقل جلسة إلى In Review أو Declined. لمعرفة لحظة تغيّر الحالة، دون إعادة تحميل الكونسول، أعدّ webhook - رابط على خادمك ترسل Didit التحديث إليه تلقائيًا.

الـ webhooks هي نمط التكامل الموصى به. الاستقصاء الدوري لنقطة نهاية القرار يعمل كخيار احتياطي، لكنه أبطأ، ويكلّف طلبات أكثر، ويفوّت أحداثًا لا تُسلَّم إلا عبر webhook - تعديلات البيانات التي يجريها المراجع، وتغيّرات حالة المعاملات، والتغيّرات على مستوى الكيانات.

#إعداد واحد

  1. المطورون → Webhooks

    افتح التطبيق وبيئة Live أو Sandbox المطلوبة، ثم المطورون وWebhooks.

  2. أضف نقطة نهاية

    اضغط إضافة نقطة نهاية، وأدخل عنوان HTTPS واسمًا واختر الأحداث. أبقِ الإصدار الموصى به v3 ما لم تدعم تكاملًا قديمًا، ثم راجع وأكّد.

  3. احفظ سر التوقيع

    لكل نقطة نهاية سر توقيع خاص يظهر مخفيًا. اضغط إظهار وأكّد هويتك؛ يُخفى مجددًا خلال 60 ثانية. احفظه في إعدادات الخادم، واتصل بالدعم إذا كان الإظهار معطّلًا. المطورون → Webhooks.

  4. إرسال حدث تجريبي

    أرسل حدثًا تجريبيًا موقّعًا للتحقق من نقطة النهاية والتوقيع ومعالجة الحدث دون تشغيل تحقق حقيقي.

وجهات webhook في كونسول Didit مع الأحداث المشترك بها وسجل التسليم
لكل وجهة أحداثها المشترك بها الخاصة، وسر توقيعها، وسجل تسليمها.

#الأحداث التي يمكنك الاشتراك بها

لا يوجد رمز بدل عام - أدرج كل عائلة أحداث تريدها. توزيعها على عدة وجهات أمر مناسب وغالبًا أنظف.

الحدثيُطلَق عند
status.updatedتغيّر حالة جلسة KYC أو KYB. الحدث الذي تريده على الأرجح تقريبًا بالتأكيد
data.updatedتعديل بيانات التحقق بعد الإنشاء - تصحيح مراجع لحقل ما
user.status.updatedانتقال مستخدم موحَّد بين ACTIVE وFLAGGED وBLOCKED
user.data.updatedتغيّر ملف تعريف مستخدم موحَّد، أو عداداته، أو معرِّفاته
business.status.updatedتغيّر حالة شركة موحَّدة
business.data.updatedتغيّر بيانات شركة موحَّدة
transaction.createdإنشاء معاملة وجهوزية قرارها الأولي
transaction.status.updatedتغيّر حالة معاملة لاحقًا
travel_rule.status.updatedتغيّر حالة تبادل Travel Rule
ملاحظة

لا يوجد session.status.updated ولا kyc.completed. إذا اشتركت في اسم غير موجود في هذه القائمة، فلن تستقبل شيئًا - وسيبدو الأمر تمامًا وكأنه فشل تسليم. تحقق من الاسم أولًا.

#ما يجب أن تفعله نقطة نهايتك

  • تحقق من التوقيع قبل أي شيء آخر. جزّئ بـ HMAC جسم الطلب الخام - لا أبدًا نسخة مُعاد تسلسلها من JSON المحلَّل، لأن إعادة التسلسل تغيّر البايتات ولن يتطابق التوقيع. استخدم مقارنة بزمن ثابت.
  • أعد 2xx بسرعة. نفّذ العمل الثقيل بشكل غير متزامن، بعد أن تستجيب.
  • كن idempotent. اعتمد على معرِّف الحدث، أو على معرِّف الجلسة + الحالة + نوع الـ webhook. إعادة المحاولة والتكرار يحدثان.
  • تعامل مع كل حالة تهمك، بما في ذلك تلك التي تصل بعد فترة طويلة من الإعداد - يمكن لجلسة مقبولة أن تنتقل لاحقًا إلى In Review عبر مراقبة AML المستمرة.
  • HTTPS فقط. نقاط النهاية بـ HTTP العادي غير مدعومة.

#إعادة المحاولة

عند استجابة الخادم برمز 5xx أو 404، يعيد Didit المحاولة مرتين، بعد نحو دقيقة ثم أربع دقائق. لا تُعاد تلقائيًا محاولة الاتصال الفاشل أو المهلة التي تتجاوز 5 ثوانٍ. استخدم إعادة الإرسال في التسليمات بعد إصلاح السبب؛ يظهر تنبيه إذا استمر الفشل.

مهم

لا تعتمد على وصول كل webhook. بعد انقطاع الخدمة، أعد الإرسال من قائمة التسليمات أو اطلب نتيجة كل جلسة لم تتلقَّ قرارها بعد.

#خلف جدار ناري أو WAF

تُسلِّم Didit من عنوان IP الثابت 18.203.201.92 بعميل مستخدم DiditWebhook/2.0. إذا كانت حافتك تحجب العملاء غير المعروفين - موقف Cloudflare الافتراضي، على سبيل المثال - اسمح بذلك العنوان لاسم المضيف المستقبِل، وإلا ستفشل عمليات التسليم قبل أن تصل إلى شيفرتك.

#لا تملك خلفية بعد؟

لا يزال بإمكانك مراقبة النتائج يدويًا في قسم Verifications بالكونسول أثناء بنائها، أو استخدام رابط تحقق بلا كود في هذه الأثناء.

#الخطوات التالية

ما زلت عالقًا؟ تحدث إلى إنسان.

أرفق معرّف مؤسستك ومعرّف الجلسة التي تسأل عنها.

تواصل مع الدعم