كيفية إضافة قدرة جديدة (API)

معلومة

هذا الدليل مخصص للعملاء الذين قاموا بالفعل بالتكامل عبر الواجهة البرمجية (POST /processes/v1) مع تصنيف مخاطر الاحتيال (Trust Network) ويضيفون التحقق من الهوية إلى عقدهم.

إضافة التحقق من الهوية

يشرح هذا الدليل تطوّر محرك القرار لتعزيز عمليات التحقق من الهوية لديك.

متطلب تقني

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

التغيير الكبير: التحقق من الهوية

التحسين الرئيسي هو القدرة على التحقق من هوية حامل الوثيقة (إضافةً إلى استجابات الاحتيال). يتحقق النظام الآن مما إذا كان الشخص الذي يقوم بالعملية هو بالفعل حامل الوثيقة المُقدَّمة.

من الضروري أن يفهم فريقك التفسير الجديد للاستجابة ويطابقه بشكل صحيح قبل تفعيل القدرة، حتى لا يتأثر تشغيلكم.

جدول مقارنة النتائج

النتيجة (Trust فقط)	النتيجة (Trust + IDUnico)	المعنى والإجراء الموصى به
N/A	APPROVED	جديد (الحالة المثالية). المستخدم هو حامل الهوية ولا توجد أي أدلة على الاحتيال.
INCONCLUSIVE	INCONCLUSIVE	تغيير في الدقة. المستخدم حقيقي ولا توجد أدلة على الاحتيال، لكن لا يوجد يقين بأنه حامل الهوية.
REPROVED	REPROVED	يُوصى بالرفض. مؤشرات احتيال، أو أكّد النظام أن المستخدم ليس حامل الهوية.
HIGH_RISK	HIGH_RISK	دليل احتيال قوي واحد على الأقل. القرار يعود للعميل.
CRITICAL_RISK	CRITICAL_RISK	دليلان حرجان على الاحتيال على الأقل. يُوصى بالرفض.

التغييرات الرئيسية في التسمية

تأكد من أن نظامك جاهز لمطابقة هذه التغييرات الثلاثة الأساسية في مسار الموافقة لديك:

1. وصول APPROVED — أصبحت هذه الآن الحالة "المثالية". إذا استلمت هذا الرمز، فلديك يقين كامل بهوية العملية وسلامتها.
2. الدقة الجديدة لـ INCONCLUSIVE — كانت في السابق إشارتك الخضراء الرئيسية. تعني الآن أن الشخص "حقيقي" ولا يوجد احتيال واضح، لكن النظام لم يتمكن من ربطه بهوية الوثيقة بيقين كامل.
3. خطورة REPROVED — إلى جانب مؤشرات الاحتيال متعددة العوامل، تشمل هذه الحالة الآن أيضاً الحالات التي ينتحل فيها المستخدم شخصية حامل الهوية.