الانتقال إلى المحتوى الرئيسي
يمرّ كل كيان مستخدم وكل كيان شركة في Didit بدورة حياة يمكن التنبؤ بها. فهم هذه الدورة مفتاح تصميم مسارات التسجيل والمراقبة المستمرة ومعالجة المشكلات.

​
مخطط دورة الحياة

​
تفاصيل الحالات

يؤدي تغيير الحالة عبر PATCH /v3/users/{vendor_data}/update-status/ أو PATCH /v3/businesses/{vendor_data}/update-status/ إلى إصدار webhook (user.status.updated / business.status.updated) حتى تتمكن الأنظمة التابعة من الاستجابة فورياً.

​
مراحل دورة الحياة

الإنشاء

يُنشأ الكيان بإحدى ثلاث طرق:
  • يُنشأ تلقائياً عند بدء جلسة مع vendor_data جديد. يُنشأ الكيان بالحالة ACTIVE.
  • يُنشأ مسبقاً عبر API باستخدام POST /v3/users/create/ أو POST /v3/businesses/create/. الحالة الافتراضية هي ACTIVE.
  • يُنشأ في وحدة التحكم بواسطة مشغّل امتثال. تبدأ الحالة بـ ACTIVE ما لم يحدد المشغّل غير ذلك.
يحصل كل كيان على uuid يولده Didit ومعرّف vendor_data يملكه العميل.

التحقق

تُرتبط الجلسات بالكيان عبر vendor_data. تمرّ كل جلسة عبر سير العمل الذي ضبطته، ويشمل ذلك التحقق من الهوية، وكشف الحيوية، ومطابقة الوجه، وفحص AML، والمستندات، والبحث في السجل للتحقق من الشركات (KYB)، وغير ذلك.تحدّث الجلسات المكتملة العدادات الإجمالية للكيان:
  • session_count، approved_count، declined_count، in_review_count
  • خريطة features: آخر حالة لكل ميزة عبر جميع الجلسات (مثلاً { "id_verification": "APPROVED", "aml": "IN_REVIEW" })
  • تنتقل حقول الملف الشخصي من آخر جلسة مقبولة (مثل full_name وdate_of_birth وportrait_image).

الاستخدام النشط

بمجرد أن يصبح للكيان جلسة مقبولة واحدة أو أكثر، يمكنك:
  • إرسال معاملات تشير إلى الكيان عبر vendor_data في حمولة المعاملة
  • تشغيل مراقبة AML المستمرة: إعادة فحص دورية لقوائم العقوبات والأشخاص المعرّضين سياسياً والأخبار السلبية
  • إعادة التحقق وفق جدول زمني: إنشاء جلسات جديدة للـ vendor_data نفسه على فترات منتظمة
  • تجميع إشارات المخاطر عبر الجلسات والمعاملات

انتقالات الحالة

تحدث تغييرات حالة الكيان تلقائياً أو يدوياً.الانتقالات التلقائية
  • ACTIVE → FLAGGED عندما تتجاوز معاملة حد المراجعة، أو عندما تضيف قاعدة الكيان إلى قائمة مراقبة.
  • ACTIVE → BLOCKED عندما تطابق السمة البيومترية للوجه إدخالاً في قائمة الحظر.
لا تضع الجلسة المرفوضة الكيان في قائمة الحظر، لذلك لا تتغير حالته. إدراج كيان مرفوض في قائمة الحظر خطوة يدوية: أضف الإدخال من صفحة قائمة الحظر أو عبر Lists API، وسيؤدي إدخال من نوع USER (وهو vendor_data) إلى تعيين الحالة إلى BLOCKED.الانتقالات اليدوية تحدث عندما يغيّر محلل الحالة من وحدة التحكم، أو عندما تستدعي نقطة النهاية update-status.يُصدر كل انتقال webhook من نوع user.status.updated أو business.status.updated.

الحذف

يُحذف الكيان عبر POST /v3/users/delete/ أو POST /v3/businesses/delete/ (على دفعات). يُزال سجل الكيان بشكل دائم. وحذف المستخدم يحذف أيضاً كل القوالب البيومترية المحتفَظ بها له بعد حذف الجلسات، فيتوقف الشخص عن المطابقة في اكتشاف التكرار وفي البحث بالوجه.لا تشمل نقاط النهاية هذه جلسات التحقق، ولا المعاملات. احذف الجلسات باستخدام Delete Session أو Batch Delete Sessions، وتُحذف المعاملات من وحدة التحكم.

​
الطوابع الزمنية للنشاط

تتتبع الكيانات نشاطها لمساعدتك على تحديد الملفات الشخصية الخاملة أو النشطة: استخدم هذه الطوابع الزمنية لتصفية الكيانات الخاملة، أو جدولة عمليات إعادة التحقق، أو تشغيل المراقبة المستمرة.

​
الأحداث الصادرة خلال دورة الحياة

راجع webhooks الخاصة بالكيانات للاطلاع على بنية الحمولات ودلالات التسليم.

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

ربط بيانات البائع

كيف يربط vendor_data الجلسات والمعاملات والكيانات ببعضها.

عمليات المستخدم

إنشاء كيانات المستخدمين وتحديثها وتغيير حالتها وحذفها.

عمليات الشركات

إنشاء كيانات الشركات وتحديثها وتغيير حالتها وحذفها.
آخر تعديل في ٧ نوفمبر ٢٠٢٦