الانتقال إلى المحتوى الرئيسي
تُقارن ميزة التحقق من قواعد البيانات من Didit بيانات هوية كل مستخدم بالمصدر المعتمد في تلك الدولة — مثل RENAPER (الأرجنتين)، وReceita Federal (البرازيل)، وTribunal Electoral (بنما، مع مطابقة بيومترية للوجه)، وJunta Central Electoral (جمهورية الدومينيكان)، والمزيد — وتتم الفوترة لكل استعلام ناجح دون حد أدنى شهري. يمثل كل إدخال في database_validations[] تقريرًا كاملاً للتحقق من قواعد البيانات — تشغيل واحد لعقدة التحقق من قواعد البيانات مقابل دولة إصدار واحدة. وتوجد نتائج السجل الخاصة بكل خدمة داخل المصفوفة الفرعية validations[] التابعة لذلك الإدخال. توثق هذه الصفحة هيكل JSON حتى تتمكن من تحليل نتائج التطابق، والبيانات المصدرية من السجل، والدرجات البيومترية التي تُرجعها كل خدمة.
تقرير Didit للتحقق من قواعد البيانات يوضح أنواع التطابق وحقول استجابة السجل

نظرة عامة

يتم إنشاء تقرير التحقق من قواعد البيانات في كل مرة تُشغّل فيها عقدة في سير العمل ميزة التحقق من قواعد البيانات. يمثل كل إدخال في مصفوفة database_validations[] تشغيل عقدة واحد مقابل دولة إصدار واحدة؛ وإذا قامت العقدة بتشغيل خدمات متعددة لتلك الدولة (على سبيل المثال CPF + CNH في البرازيل)، فستظهر كل خدمة كعنصر منفصل داخل المصفوفة الفرعية validations[] التابعة لهذا الإدخال. يحتوي كل تقرير على:
  • status العام للميزة — قيمة FeatureStatusChoices (Not Finished أو Approved أو Declined أو In Review).
  • نوع التطابق التراكمي match_type (full_match أو partial_match أو no_match، أو null عندما لا تُرجع أي خدمة نتيجة قابلة للاستخدام) مجمّع عبر الخدمات من خلال طريقة التطابق.
  • issuing_state (وفق معيار ISO 3166-1 alpha-3) وvalidation_type المشتق (one_by_one أو two_by_two أو not_enabled — ولا يكون null أبدًا).
  • كتلة screened_data — البيانات المقدمة من المستخدم التي تم إرسالها إلى السجل.
  • مصفوفة validations[] — إدخال واحد لكل خدمة أنتجت نتيجة، مع service_id/service_name من الدليل، وoutcome_code المحايد عن المورّدين، وoutcome_detail اختياري، وخريطة validation لكل حقل، وsource_data المُنقّحة والمستخرجة من استجابة السجل.
  • مصفوفة errors[] — أخطاء خاصة بكل خدمة عند فشل البحث أو تخطيه؛ ويكون هذا المفتاح محذوفًا تمامًا في حال عدم وجود أخطاء.
  • مصفوفة warnings[] — أحداث المخاطر الصادرة أثناء التحقق (راجع تحذيرات التحقق من قواعد البيانات).
  • حقل node_id يحدد عقدة مخطط سير العمل التي أنتجت التقرير (جلسات V3 فقط).

أين يظهر في استجابات API

يظهر التقرير كـ database_validations[] في GET /v3/session/{sessionId}/decision/ — دائمًا كمصفوفة JSON، وليس ككائن مفرد مطلقًا. تحتوي المصفوفة على إدخال واحد لكل عقدة تحقق من قواعد البيانات في مخطط سير العمل؛ وبدورها، تحتوي المصفوفة الفرعية validations[] لكل إدخال على عنصر واحد لكل خدمة سجل أنتجت نتيجة.
تشير القيمة null إلى أنه لم يتم تشغيل أي خطوة تحقق من قواعد البيانات بعد.

المخطط

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

قيم الحالة

تستخدم status التعداد القياسي على مستوى الميزة (راجع تعدادات الحالة) — راجع مرجع تعدادات الحالة. يحدد التعداد أيضاً Resub Requested، وهو ما لا يُنتجه التحقق من قواعد البيانات عملياً. تُطبَّق قواعد الحالة المخصصة لكل عقدة فوق هذه الحالة الأساسية. راجع تحذيرات التحقق من قواعد البيانات للاطلاع على الإجراءات القابلة للتهيئة وقيمها الافتراضية.

رموز النتائج

يحمل كل إدخال في validations[] رمز outcome_code محايداً للمزودين — وهو أحد الرموز التالية: MATCH، أو PARTIAL_MATCH، أو NO_MATCH، أو DOCUMENT_NOT_FOUND، أو INVALID_DOCUMENT_FORMAT، أو INVALID_INPUT، أو MINOR_BLOCKED، أو DECEASED، أو BIOMETRIC_NO_MATCH، أو BIOMETRIC_IMAGE_UNUSABLE، أو INCONCLUSIVE، أو DOCUMENT_SUPERSEDED، أو REGISTRY_UNAVAILABLE، أو REGISTRY_ERROR. انتبه إلى الفروق: يعني NO_MATCH أن السجل لم يؤكد البيانات بشكل قاطع، ويعني INCONCLUSIVE أن السجل تعذر عليه تحديد النتيجة بأي من الاتجاهين (يتم التوجيه إلى المراجعة، وليس الرفض)، بينما BIOMETRIC_IMAGE_UNUSABLE هي مشكلة فنية في صورة سيلفي (إعادة التقاط) — على عكس BIOMETRIC_NO_MATCH القاطعة. راجع التصنيف الكامل وطريقة التعامل الموصى بها في صفحة رموز النتائج.

إدخال واحد لكل خدمة

تحتوي مصفوفة validations[] على عنصر واحد لكل خدمة أنتجت payload للنتيجة (كائن validation، أو source_data، أو outcome_code، أو outcome_detail). إذا كان سير العمل لديك يُشغّل خدمات متعددة لنفس الدولة (على سبيل المثال Brazil CPF + Brazil CNH)، فستظهر كل خدمة بشكل منفصل مع service_id وoutcome_code وsource_data الخاصة بها. وتعمل القيمة الإجمالية match_type على التجميع عبر جميع الخدمات (أي تطابق كامل → full_match؛ وإلا فإن أي تطابق جزئي → partial_match؛ وإلا no_match)، وتُشتق validation_type من عدد الخدمات المختلفة التي تطابقت بالكامل — راجع طرق التطابق.

عناوين URL الموقعة مسبقاً للصور

تُعاد حقول الصور في source_data (photo، signature) وscreened_data (selfie، cnh_qr_code_image، document_image) في صورة عناوين URL موقعة مسبقاً تنتهي صلاحيتها — يمكنك تحديثها عبر إعادة استدعاء endpoint القرار. ولا يتم كشف payload الخام الوارد من المصدر عبر API عن قصد.

أمثلة

مقبولة — التحقق من حالة CPF في البرازيل (Receita Federal)

مقبولة — التحقق البيومتري من DNI في الأرجنتين (RENAPER)

بالنسبة للأرجنتين، يستخدم التحقق RENAPER مع مطابقة الوجه البيومترية. تتضمن الاستجابة face_match_score وحقول هوية إضافية يعيدها السجل.

قيد المراجعة — تعذر تشغيل السجل

عندما لا تُعيد أي خدمة نتيجة قابلة للاستخدام — كأن تكون الحقول المطلوبة مفقودة أو غير صحيحة، أو يتعذر الوصول إلى السجل — تظل match_type بقيمة null، وتكون validation_type بقيمة not_enabled، ويصدر تحذير COULD_NOT_PERFORM_DATABASE_VALIDATION، وتنتقل الميزة إلى In Review حتى يتم تصحيح البيانات. لا تُفرض رسوم على الخدمات التي تم تخطيها.
املأ الحقل المفقود من صفحة تفاصيل الجلسة في Console — حيث يؤدي حفظه إلى إعادة تشغيل الفحص تلقائياً وإزالة التحذير عند النجاح.

ذات صلة

آخر تعديل في ٧ نوفمبر ٢٠٢٦