كيفية إضافة إمكانية جديدة (API)
هذا الدليل موجّه للعملاء المدمجين مسبقًا عبر API (POST /processes/v1) مع تصنيف مخاطر الاحتيال (Trust Network) والذين يضيفون التحقق من الهوية إلى عقدهم.
إضافة التحقق من الهوية
يوضّح هذا الدليل تطوّر محرك القرار لتعزيز عمليات التحقق من الهوية الخاصة بك.
على عكس عمليات التكامل الأخرى، فإن تفعيل هذه الإمكانية يتطلب تحديث مفتاح API الخاص بك. بدون هذا التغيير، لن تتمكن من استلام استجابات التحقق من الهوية الجديدة — سيشاركها معك جهة الاتصال الخاصة بك في Unico.
التغيير الكبير: التحقق من الهوية
التحسين الرئيسي هو القدرة على التحقق من هوية حامل الوثيقة (بالإضافة إلى استجابات الاحتيال). يتحقق النظام الآن مما إذا كان الشخص الذي يقوم بالعملية هو بالفعل حامل الوثيقة المقدَّمة.
من الضروري أن يفهم فريقك بشكل صحيح تفسير الاستجابة الجديد ويحدد كيفية التعامل معه قبل تفعيل الإمكانية، لتجنّب التأثير على عملياتك.
جدول مقارنة النتائج
| النتيجة (Trust فقط) | النتيجة (Trust + IDUnico) | المعنى والإجراء الموصى به |
|---|---|---|
| غير متاح | APPROVED | جديد (الحالة المثالية). المستخدم هو حامل الوثيقة ولا توجد أدلة على الاحتيال. |
INCONCLUSIVE | INCONCLUSIVE | تغيير في الدلالة. المستخدم حقيقي ولا توجد أدلة على الاحتيال، ولكن لا يوجد تأكيد بأنه حامل الوثيقة. |
REPROVED | REPROVED | يوصى بالرفض. مؤشرات احتيال، أو أكّد النظام أن المستخدم ليس حامل الوثيقة. |
HIGH_RISK | HIGH_RISK | دليل قوي واحد على الأقل على الاحتيال. القرار يعود للعميل. |
CRITICAL_RISK | CRITICAL_RISK | دليلان حرجان على الأقل على الاحتيال. يوصى بالرفض. |
التغييرات الأساسية في التسميات
تأكد من أن نظامك جاهز لتعيين هذه التغييرات الثلاثة الأساسية في تدفق الموافقة الخاص بك:
- ظهور
APPROVED— تُعد الآن الحالة "المثالية". إذا استلمت هذا الرمز، فلديك تأكد كامل من هوية العملية وسلامتها. - الدلالة الجديدة لـ
INCONCLUSIVE— كانت سابقًا إشارتك الرئيسية للموافقة. الآن تعني أن الشخص "حقيقي" ولا يوجد احتيال واضح، ولكن لم يتمكن النظام من ربطه بهوية الوثيقة بتأكيد كامل. - خطورة
REPROVED— بالإضافة إلى مؤشرات الاحتيال متعددة العوامل، تشمل هذه الحالة الآن أيضًا الحالات التي ينتحل فيها المستخدم شخصية حامل الوثيقة.