GET /v3/session/<id>/decision/ وكل webhook من Didit.
جميع قيم الحالة
كل حالة هي سلسلة نصية مطابقة تماماً تُرجعها واجهة API الخاصة بـ Didit وwebhooks. استخدم دائماً المطابقة الصارمة للسلاسل النصية في كودك (مثلاً
=== "In Review")، فهذه القيم حساسة لحالة الأحرف وتتضمن مسافات. كما أن القيمة Kyc Expired تستخدم حرف K كبيراً واحداً فقط، وليس KYC.حالات الجلسة
لم تبدأ - "Not Started"
لم تبدأ - "Not Started"
القيمة في API:
"Not Started"تم إنشاء الجلسة عبر API، لكن المستخدم لم يفتح رابط التحقق بعد.- ما الذي يجب فعله: انتظر حتى يبدأ المستخدم، أو أرسل تذكيرًا إذا مرّ وقت طويل.
- ينتقل إلى:
"In Progress"،"Expired"
قيد التقدم - "In Progress"
قيد التقدم - "In Progress"
القيمة في API:
"In Progress"فتح المستخدم الرابط، وهو ينفّذ خطوات التحقق حاليًا (التقاط المستند، وكشف الحيوية، وغير ذلك).- ما الذي يجب فعله: لا يلزم أي إجراء، فالمستخدم يتابع سير التحقق.
- ينتقل إلى:
"Approved"،"Declined"،"In Review"،"Abandoned"
مقبولة - "Approved"
مقبولة - "Approved"
القيمة في API:
"Approved"نجحت جميع فحوصات التحقق. تم التحقق من هوية المستخدم.- ما الذي يجب فعله: امنح المستخدم الوصول، وحدّث ملفه الشخصي، واحفظ بيانات القرار.
- يتضمن الـ webhook: كائن
decisionكاملًا مع نتائج جميع الميزات. - ينتقل إلى:
"Kyc Expired"(عند تجاوز تاريخ انتهاء صلاحية المستند الذي جرى التحقق منه، وهذا هو السلوك الافتراضي ما لم تكن Expiration mode مضبوطة على Allow expired لذلك البلد ونوع المستند). ويمكن للمراجع أو لـ endpoint تحديث الحالة أيضًا أن يعيّنها إلى"Declined"أو"Resubmitted".
مرفوضة - "Declined"
مرفوضة - "Declined"
القيمة في API:
"Declined"فشل فحص واحد أو أكثر من فحوصات التحقق. لم يجتز المستخدم التحقق.- ما الذي يجب فعله: أبلغ المستخدم. واطلب إعادة التقديم اختياريًا إذا كانت المشكلة قابلة للإصلاح.
- يتضمن الـ webhook: كائن
decisionكاملًا مع التحذيرات التي تشرح سبب الفشل. - ينتقل إلى:
"Resubmitted"(إذا طلب ذلك المراجع). ويمكن للمراجع أو لـ endpoint تحديث الحالة أيضًا أن يعيّنها إلى"Approved".
قيد المراجعة - "In Review"
قيد المراجعة - "In Review"
القيمة في API:
"In Review"رصدت الفحوصات الآلية تحذيرات تحتاج إلى مراجعة بشرية. يجب أن يتخذ مراجع الامتثال القرار النهائي.- ما الذي يجب فعله: ينبغي للمراجع فتح الجلسة في Console، ثم اعتمادها أو رفضها أو طلب إعادة التقديم.
- يتضمن الـ webhook: كائن
decisionكاملًا مع التحذيرات. - ينتقل إلى:
"Approved"،"Declined"،"Resubmitted"
بانتظار المستخدم - "Awaiting User"
بانتظار المستخدم - "Awaiting User"
القيمة في API:
"Awaiting User"تُستخدم في جلسات KYB (التحقق من الشركات) عندما ترسل خطوة الأشخاص الرئيسيين قائمة الأطراف، فتُنشئ جلسات KYC أو KYB فرعية. تنتظر الجلسة الأم حتى يُكمل جميع الأطراف المطلوبون عملية التحقق الفردية.- ما الذي يجب فعله: راقب حالات جلسات KYC الفرعية. وبمجرد أن تصل جلسات جميع الأطراف المطلوبة إلى حالة نهائية (مقبولة أو مرفوضة أو منتهية الصلاحية)، تُعيد الجلسة الأم تحديد حالتها النهائية تلقائيًا.
- يتضمن الـ webhook: القائمة الحالية للأطراف وحالات جلساتهم الفرعية.
- ينتقل إلى:
"Approved"،"Declined"،"In Review"(عندما تصبح جميع الجلسات الفرعية نهائية) - ينتقل من:
"In Progress"(بعد إرسال خطوة الأشخاص الرئيسيين) - ملاحظة: إذا أُعيد تقديم جلسة KYC فرعية، تعود الجلسة الأم إلى
"Awaiting User"إلى أن تكتمل الجلسة المعاد تقديمها. ويتقدّم فحص السجل KYB (KYB Registry Check) الذي حالته"Declined"على"Awaiting User".
أُعيد التقديم - "Resubmitted"
أُعيد التقديم - "Resubmitted"
القيمة في API:
"Resubmitted"طلب المراجِع من المستخدم إعادة تنفيذ خطوات تحقق محددة (مثلًا إعادة التقاط صورة مستند غير واضحة).- ما الذي يجب فعله: انتظر حتى يُكمل المستخدم الخطوات المطلوب إعادتها. سيعيد النظام التقييم تلقائيًا.
- يتضمن الـ webhook: كائن
resubmit_infoيحتوي على قائمة الميزات المطلوب إعادة تنفيذها وأسبابها. - ينتقل إلى:
"Approved"،"Declined"،"In Review"، أو"Abandoned"عندما تنتهي نافذة الجلسة قبل أن يعيد الشخص تنفيذ الخطوات.
منتهية الصلاحية - "Expired"
منتهية الصلاحية - "Expired"
القيمة في API:
"Expired"انتهت مهلة الجلسة قبل أن يفتح المستخدم رابط التحقق.- ما الذي يجب فعله: أنشئ جلسة جديدة، وأرسل للمستخدم رابطًا جديدًا.
- حالة نهائية: لا توجد انتقالات أخرى.
متروكة - "Abandoned"
متروكة - "Abandoned"
القيمة في API:
"Abandoned"بدأ المستخدم التحقق لكنه لم يُنهِه ضمن المهلة المسموح بها.- ما الذي يجب فعله: أرسل تذكيرًا، أو أنشئ جلسة جديدة.
- لا توجد انتقالات تلقائية. يمكن للمراجع، أو لـ
PATCH /v3/session/{sessionId}/update-status/، أن يعيّنها إلى"Approved"أو"Declined"أو"Resubmitted".
KYC منتهي الصلاحية - "Kyc Expired"
KYC منتهي الصلاحية - "Kyc Expired"
القيمة في API:
"Kyc Expired"انتهى تاريخ صلاحية المستند الذي جرى التحقق منه خلال الجلسة. المُشغِّل هو هذا التاريخ، وليس مدة تُقاس من تاريخ الموافقة، ولا يُرسل أي تنبيه مسبق.- ما الذي يجب فعله: اطلب من المستخدم إعادة التحقق عبر جلسة جديدة. يُبلّغ حدث
status.updatedبالانتقال، وتتضمن نتيجة التحقق من الهوية التحذيرDOCUMENT_EXPIRED. - يتحكم فيه: Expiration mode لذلك البلد ونوع المستند في ID verification → Additional settings by country & document type. Reject expired (الافتراضي) يراقب المستند، أما Allow expired فيعني أن الجلسة لا تنتقل إلى هذه الحالة أبدًا.
- لا توجد انتقالات تلقائية. يمكن للمراجع، أو لـ
PATCH /v3/session/{sessionId}/update-status/، أن يعيّنها إلى"Approved"أو"Declined"أو"Resubmitted".
انتقالات الحالة
مخطط دورة الحياة
الحالات النهائية وغير النهائية
التعامل مع الحالات في الكود
استخدم webhooks أو واجهة برمجة استرجاع الجلسة للاستجابة لتغييرات الحالة.إعادة التقديم
تتيح حالة مُعاد التقديم لفريق الامتثال لديك منح المستخدمين فرصة ثانية دون إنشاء جلسة جديدة.1
يبدأ المراجع إعادة التقديم
من Console، افتح جلسة
In Review أو Declined وانقر على طلب إعادة التقديم. حدّد الخطوات التي تحتاج إلى إعادة التنفيذ.2
أرشفة البيانات السابقة
يعيد النظام ضبط الميزات المحددة ويضع علامة
previous_attempt على البيانات السابقة، مع الحفاظ على سجل التدقيق الكامل.3
إشعار المستخدم
إذا كان البريد الإلكتروني متاحاً، يتلقى المستخدم رسالة بريد إلكتروني مترجمة إلى لغته تحتوي على رابط مباشر للمتابعة.
4
يعيد المستخدم تنفيذ خطوات محددة
يكرر المستخدم الخطوات المُعلَّمة فقط، وليس التحقق بأكمله.
5
يعيد النظام التقييم
عند الاكتمال، تنتقل الجلسة تلقائياً إلى
"Approved" أو "Declined" أو "In Review".حمولة webhook الخاصة بإعادة التقديم
reasons كل node_id أُعيد تقديمه بكود التحذير الخاص بالسجل الأكثر صلة بتلك الخطوة (وهي الأكواد نفسها التي يعرضها القرار)، فيمكنك ربطه بنسختك الخاصة. وهو أيضاً الكود الذي تُحوّله شاشة إعادة التقديم في التدفق المستضاف ورسالة إعادة التقديم إلى نص محلي للمستخدم، باستثناء التحذيرات التي قد تكشف إشارة فحص أو احتيال (التكرار وAML وقائمة الحظر والفحوصات عبر المؤسسات وسلامة الموقع وما شابهها). في هذه الحالات يرى الشخص سبباً عاماً، أما resubmit_info.reasons في webhook فيتضمن دائماً الكود الحقيقي. لا يظهر أي إدخال للخطوة التي لم يُسجَّل لها أي تحذير.
أي الميزات يمكن إعادة تقديمها؟
أي ميزة بحالة غير مقبولة: مرفوضة، قيد المراجعة، غير مكتملة، لم تبدأ، أو منتهية الصلاحية.أفضل الممارسات
مراقبة حالة قيد المراجعة
اضبط التنبيهات (عبر البريد الإلكتروني أو Slack) في Didit Console لتتلقى إشعارًا عندما تحتاج الجلسات إلى مراجعة يدوية.
تفضيل إعادة التقديم
إذا كانت المشكلة قابلة للإصلاح (صورة غير واضحة، أو الجانب الخاطئ من المستند)، فاطلب إعادة التقديم بدلًا من الرفض. يؤدي ذلك إلى تحسين معدل التحويل.
تتبّع حالات التسرّب
قد تشير معدلات الحالات المتروكة أو منتهية الصلاحية المرتفعة إلى احتكاك في تجربة المستخدم. فكّر في تعديل TTL الخاص بالجلسة أو تحسين إرشادات المستخدم.
معالجات Idempotent
قد تُعاد محاولة إرسال webhook. استخدم
session_id كمفتاح فريد لتضمن معالجة كل تغيير في الحالة مرة واحدة فقط.