الانتقال إلى المحتوى الرئيسي

نظرة عامة

يتبع كل تقرير خاص بميزة شكل المُسلسِل V3 المعرَّف في service-didit-verification. يظهر الكائن نفسه في ثلاثة مواضع، لذلك فإن المخطط الموجود هنا هو المصدر المرجعي الوحيد لجميع هذه المواضع:
  • GET /v3/session/{sessionId}/decision/: تُعاد كل ميزة في مصفوفة بصيغة الجمع (id_verifications[]، nfc_verifications[]، liveness_checks[]، face_matches[]، poa_verifications[]، phone_verifications[]، email_verifications[]، aml_screenings[]، ip_analyses[]، database_validations[]، questionnaire_responses[]، signatures[]، bank_verifications[] (راجع طرق التحقق البنكي)، والمكافئات الخاصة بـ KYB وهي registry_checks[] وdocument_verifications[] وkey_people_checks[]).
  • حمولات webhook (status.updated وdata.updated): الشكل نفسه داخل الغلاف decision.
  • واجهات برمجة التطبيقات المستقلة: تعيد الاستجابات ككائن واحد (البحث بالوجه وتقدير العمر والمصادقة البيومترية) وتستخدم مجموعة الحقول نفسها.
قدّم V3 سير العمل متعدد المثيلات: يحمل كل كائن ميزة الحقل node_id الذي يربط التقرير بعقدة الرسم البياني لسير العمل التي أنتجته. أما endpoints V2 (بصيغة المفرد، مثل kyc وface وaml)، فما زالت متوافقة مع الإصدارات السابقة، لكنها تعيد أول مثيل فقط.

الحقول المشتركة

يعرض كل كائن تقرير الحقول التالية: حقول الوسائط (portrait_image وfront_image وdocument_file و…) روابط موقعة مسبقاً بنافذة صلاحية محدودة، لذا نزّلها فوراً بدلاً من تخزين الرابط. تُعرض الأمثلة بالصيغة https://<media-host>/....

كائن التحذير

يُعاد في كل مصفوفة warnings[]. المخطط من logs/serializers/log.py:8-65 (LogV3Serializer).

كائنات التقارير

تغطي الأقسام المتبقية كل كائن تقرير خاص بكل ميزة. نص عنوان H3 ثابت عمداً حتى تتمكن الوثائق الأخرى من الربط المباشر به.

التحقق من الهوية

يتم إرجاعه لكل مستند KYC/هوية يقدمه المستخدم. يظهر كـ id_verifications[] في GET /v3/session/{sessionId}/decision/ وداخل الحقل kyc في استجابات V2. المصدر: kyc/serializers/kyc.py:383-414 (IDVerificationV3Serializer، يرث من IDVerificationV2Serializer في kyc/serializers/kyc.py:320-380).
النسخة نفسها مع طريقة غير المستند. تتغير المفاتيح الخاصة بالطريقة فقط؛ وكل ما تملؤه قراءة المستند يُملأ بدلاً من ذلك من سجل الجهة الرسمية أو من سمات المحفظة، والمفاتيح التي لا تنطبق تكون null.

التحقق عبر NFC

يُرجَع لكل قراءة لشريحة في مستند هوية: شريحة ePassport أو eID وفق ICAO 9303، أو قراءة بطاقة My Number اليابانية عبر JPKI (chip_protocol: "jpki"). يظهر كـ nfc_verifications[] في GET /v3/session/{sessionId}/decision/ (واحد لكل سجل KYC رئيسي). المصدر: kyc/serializers/epassport.py:121-139 (NFCV3Serializer، ويمتد من NFCV2Serializer في kyc/serializers/epassport.py:83-118).

كشف الحيوية

تُعاد لكل جلسة حيوية. تظهر كـ liveness_checks[] في GET /v3/session/{sessionId}/decision/. المصدر: face/serializers/face.py:301-320 (LivenessV3Serializer، ويمتد من LivenessV2Serializer في face/serializers/face.py:216-298).
تعيد الجلسة السلبية هذا الحقل عندما تحفظ عملية الالتقاط تسجيلاً، وتعيد null عندما لا تحتفظ الجلسة بأي تسجيل. والمثال أعلاه لجلسة لم تحتفظ بأي تسجيل.

مطابقة الوجه

تُعاد لكل مقارنة مطابقة وجه (عادةً بين وجه المستخدم في فحص الحيوية وصورة الوجه في المستند). تظهر كـ face_matches[] في GET /v3/session/{sessionId}/decision/. المصدر: face/serializers/face.py:367-389 (FaceMatchV3Serializer، ويمتد من FaceMatchV2Serializer في face/serializers/face.py:323-364).

البحث بالوجه

تُرجَع من واجهة API البحث بالوجه المستقلة (POST /v3/face-search/). لا يظهر البحث بالوجه أبدًا كمصفوفة في /v3/session/{sessionId}/decision/. وعند حفظه باستخدام save_api_request=true، تظهر الجلسة هناك كعنصر FACE_SEARCH ضمن features[]، مع عنصر liveness_checks[] يحمل matches المحفوظة. المصادر: apis/serializers/face_search.py:8-79 (FaceSearchResponseSerializer الذي يغلّف FaceSearchDetailsSerializer)، وتُبنى قواميس التطابق في face/utils/utils.py:869-884. الاستجابة على المستوى الأعلى: كائن face_search:

كائن تطابق البحث بالوجه

فحص AML

يُعاد لكل كيان يخضع للفحص. يظهر كمصفوفة aml_screenings[] في GET /v3/session/{sessionId}/decision/ لكل من جلسات KYC وKYB. المصدر: aml/serializers/aml.py:63-85 (AMLV3Serializer، الذي يمتد من AMLV2Serializer في aml/serializers/aml.py:28-60).

تحليل عنوان

يُرجَع لكل موقع شبكة يتم التقاطه. يظهر كـ ip_analyses[] في GET /v3/session/{sessionId}/decision/ لجلسات KYC وKYB على حد سواء. المصدر: kyc/serializers/location.py:196-243 (IPAnalysisSerializerV3).

التحقق من الموقع

يُرجَع لكل خطوة تحقق من الموقع. يظهر كـ geolocation_checks[] في GET /v3/session/{sessionId}/decision/: عنصر واحد لكل خطوة، وهو محاولتها المقبولة. يسرد geolocation_attempts[] كل محاولة لكل خطوة، من الأقدم إلى الأحدث. وتكون كلتاهما null لسير العمل الذي لا يتضمن الخطوة. المصدر: GeolocationDecisionSerializer. تظهر جميع الحقول والأمثلة في تقرير التحقق من الموقع.

إثبات العنوان

يُعاد لكل مستند عنوان مقدَّم. يظهر كـ poa_verifications[] في GET /v3/session/{sessionId}/decision/. المصدر: poa/serializers/poa.py:212-227 (POAV3Serializer، يمتد من POAV2Serializer في poa/serializers/poa.py:173-209).

التحقق من رقم الهاتف

يُعاد لكل محاولة تحقق من رقم الهاتف. يظهر بوصفه phone_verifications[] في GET /v3/session/{sessionId}/decision/ لجلسات KYC وKYB على حد سواء. المصدر: phone/serializers/phone.py:251-266 (PhoneV3Serializer، ويمتد من PhoneV2Serializer في phone/serializers/phone.py:103-248).

التحقق من البريد الإلكتروني

يُعاد لكل محاولة تحقق من البريد الإلكتروني. يظهر بوصفه email_verifications[] في GET /v3/session/{sessionId}/decision/ لجلسات KYC وKYB على حد سواء. المصدر: email_verification/serializers/email.py:149-164 (EmailV3Serializer، ويمتد من EmailV2Serializer في email_verification/serializers/email.py:38-146).

التحقق من قواعد البيانات

يُعاد لكل عملية بحث في قاعدة بيانات تُجرى على البيانات التي أرسلها المستخدم. يظهر بوصفه database_validations[] في GET /v3/session/{sessionId}/decision/. المصدر: database_validation/serializers/database_validation.py:21-142 (DatabaseValidationV3Serializer، ويمتد من DatabaseValidationV2Serializer).

استجابة الاستبيان

تُعاد لكل إرسال استبيان. تظهر كعنصر questionnaire_responses[] في GET /v3/session/{sessionId}/decision/ لجلسات KYC وKYB على حد سواء. المصدر: questionnaires/serializers/questionnaire.py:591-597 (QuestionnaireResponseV3Serializer، ويمتد من QuestionnaireResponseSerializer في questionnaires/serializers/questionnaire.py:520-588).

التوقيع الإلكتروني

تُعاد لكل موقّع في خطوة التوقيع الإلكتروني. تظهر كعنصر signatures[] في GET /v3/session/{sessionId}/decision/ لجلسات KYC وKYB على حد سواء، وذلك فقط عندما يتضمن سير العمل هذه الخطوة. على خلاف كائنات التقارير الأخرى، فإن status فيه هو مرحلة التوقيع، ونتيجته في verdict، وعناصر warnings[] فيه هي { code, node_id } وليست كائنات التحذير. يتضمن تقرير التوقيع الإلكتروني مثالاً كاملاً وجميع الحقول المتداخلة.

تقدير العمر

تُعيدها واجهة API المستقلة لتقدير العمر (POST /v3/age-estimation/). تتضمّن الاستجابة مجموعة فرعية من بنية Liveness check ضمن غلاف age_estimation: وهي status وmethod وscore وage_estimation وwarnings، بالإضافة إلى كتلة user_image الخاصة بكشف الوجه والمتاحة في الواجهة المستقلة فقط؛ وهي لا تتضمّن reference_image أو video_url أو matches أو face_quality أو face_luminance. وفي جلسات سير العمل لا توجد مصفوفة منفصلة، بل يظهر العمر المقدَّر ضمن liveness_checks[].age_estimation في GET /v3/session/{sessionId}/decision/. المصدر: apis/serializers/age_estimation.py:50-55 (AgeEstimationResponseSerializer)، ويُجمَّع الغلاف في apis/views/age_estimation.py:138-174.

المصادقة البيومترية

تُشغّل المصادقة البيومترية مسار كشف الحيوية + مطابقة الوجه نفسه المستخدم في KYC القياسي، لكنها مُعدّة لمقارنة الوجه الملتقَط بصورة المرجع الموجودة لدى المستخدم، بدلاً من صورة الوجه في مستند استُخرجت حديثاً عبر OCR. لا يوجد مُسلسِل مخصص لها، إذ تُعيد GET /v3/session/{sessionId}/decision/ الكائنين القياسيين فحص الحيوية ومطابقة الوجه ضمن liveness_checks[] وface_matches[]. يُضبط سير عمل الجلسة بالقيمة workflow_type = "biometric_authentication" (WorkflowTypeChoices، common/config/choices.py:636).

سجل KYB

يُعاد لكل شركة مؤكّدة من السجل في سير عمل KYB. يظهر كعنصر registry_checks[] في GET /v3/session/{sessionId}/decision/ لجلسات الشركات. المصدر: kyb/serializers/kyb.py:939-964 (RegistryCheckV3Serializer).

كائن الشركة

المصدر: kyb/serializers/kyb.py:220-321 (KYBCompanyResponseSerializer).

مستند KYB

يُرجَع لكل عقدة تجمع مستندات KYB الداعمة. يظهر بوصفه document_verifications[] في GET /v3/session/{sessionId}/decision/ لجلسات الشركات، بمدخل واحد لكل node_id، مع قائمة items[] تعرض كل مستند تم رفعه. المصدر: kyb/serializers/kyb.py:1053-1068 (DocumentVerificationV3Serializer)؛ ويتبع كل عنصر kyb/serializers/kyb.py:811-851 (KYBDocumentResponseSerializer).

كائن عنصر مستند KYB

الشخص الرئيسي في KYB

يُرجَع لكل عقدة للأشخاص الرئيسيين في سير عمل KYB. يظهر بوصفه key_people_checks[] في GET /v3/session/{sessionId}/decision/ لجلسات الشركات. المصدر: kyb/serializers/kyb.py:967-1050 (KeyPeopleCheckV3Serializer).

الحقول على مستوى القرار

تقع هذه المفاتيح بجوار مصفوفات الميزات في GET /v3/session/{sessionId}/decision/ وداخل حقل decision في webhook. راجع استرجاع الجلسة لمعرفة كيفية قراءتها.

الموافقة البيومترية

يحمل كل قرار تحقق من المستخدمين وكل webhook للجلسة كائن biometric_consent واحدًا (وليس مصفوفة): ما إذا كانت الجلسة تتطلب موافقة بيومترية صريحة، والسبب، وأدلة الإجابة. يكون null عندما لم تُقيَّم الجلسة قط، مثل سير عمل بلا التقاط للوجه. المصدر: BiometricConsentDecisionSerializer (sessions/serializers/biometric_consent.py). تُشرح الخطوة ومتى تظهر وما تعنيه كل حالة في الموافقة البيومترية. الحقول التي لا توجد لها قيمة مسجلة تكون null، وليس نصًا فارغًا أبدًا. جلسة في إلينوي عالجها SDK أصلي بإصدار أقل من 4.10.0، والتقط السيلفي دون الخطوة:
شخص يستخدم VPN يتصل عبر خادم خارج الولايات المتحدة، ووافق في الصفحة المستضافة للتحقق:

مرجع قيم الحالة

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

حالات مستوى الميزة

تُستخدم في حقل status لكل كائن تقرير. المصدر: common/config/choices.py:343-348 (FeatureStatusChoices). يمكن أن تظهر حالة Expired أيضًا في التحقق من رقم الهاتف والبريد الإلكتروني والهوية عندما تنتهي مهلة خطوتها (PhoneStatusChoices في common/config/choices.py:377-382، وEmailStatusChoices في common/config/choices.py:434-439).

حالات مستوى الجلسة

تُستخدم في حقل status ذي المستوى الأعلى للجلسة الأم. المصدر: common/config/choices.py:106-117 (StatusChoices).
القيم النهائية للجلسة هي Approved وDeclined وIn Review وExpired وKyc Expired وAbandoned. يمكن أن تصل الجلسة إلى قرارها الإجمالي بينما تبقى ميزة فردية في حالة In Review.
آخر تعديل في ١٤ نوفمبر ٢٠٢٦