الانتقال إلى المحتوى الرئيسي
يلتقط تقرير التحقق من البريد الإلكتروني النتيجة الكاملة لتحدي OTP للبريد الإلكتروني: الجهة التي أُرسلت إليها الرسالة، وما إذا كان العنوان مؤقتاً أو غير قابل للتسليم، وما إذا كان يظهر في اختراقات بيانات معروفة، وعدد المحاولات التي أجراها المستخدم، وأي حالات تطابق عبر الجلسات مع قائمة الحظر الخاصة بك أو مع مستخدمين آخرين مقبولة بياناتهم. توثق هذه الصفحة هيكل JSON الذي يُرجعه endpoint القرار حتى تتمكن من تحليل نتائج OTP، والتعرض للاختراقات، ومؤشرات المخاطر لكل عنوان تم التحقق منه.
Didit email verification report showing OTP outcome, breach data and risk flags

نظرة عامة

يتم إنشاء تقرير البريد الإلكتروني في كل مرة تُشغّل فيها عقدة سير العمل ميزة التحقق من البريد الإلكتروني. يمثل كل تقرير تحدي OTP واحداً لعنوان واحد ويحتوي على:
  • عنوان email الذي تم التحقق منه.
  • مؤشرات مخاطر منطقية (is_breached وis_disposable وis_undeliverable) ومصفوفة breaches[] الداعمة المستخرجة من قاعدة بيانات معلومات الاختراقات.
  • عدد محاولات إرسال OTP (verification_attempts) والطابع الزمني للموافقة.
  • سجل lifecycle[] زمني لكل محاولة إرسال وإعادة محاولة والتحقق من الرمز.
  • مصفوفة matches[] تُظهر نفس العنوان في عمليات تحقق مقبولة أخرى من البريد الإلكتروني أو في قائمة الحظر الخاصة بك.
  • مصفوفة warnings[] — أحداث مخاطر صادرة أثناء التحقق (انظر تحذيرات التحقق من البريد الإلكتروني).
  • معرّف node_id يحدد أي عقدة في مخطط سير العمل أنتجت التقرير (جلسات V3 فقط).
في جلسات سير العمل المستضافة، يتم تشغيل تحدي OTP داخل واجهة مستخدم التحقق الخاصة بـ Didit — وما عليك سوى قراءة النتيجة من payload القرار. ولإجراء OTP من خادم إلى خادم بدون تدفق مستضاف، استخدم Email API المستقلة: يُسلّم endpoint POST /v3/email/send/ الرمز ويتحقق endpoint POST /v3/email/check/ من إدخال المستخدم؛ وتظهر عمليات التحقق المستقلة المكتملة من خلال نفس هيكل التقرير. تحدد الجلسات المستضافة الحد الأقصى للمستخدم افتراضياً بـ إدخالين خاطئين للرمز (email_max_check_attempts) ومرتي إرسال لرمز OTP — الإرسال الأولي بالإضافة إلى إعادة إرسال واحدة (email_max_retries)، وهو أمر قابل للتعديل لكل عقدة سير عمل. يؤدي تجاوز أي من الحدين إلى إنهاء الخطوة بحالة Declined مع EMAIL_CODE_ATTEMPTS_EXCEEDED.

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

يُرجع endpoint القرار (GET /v3/session/{sessionId}/decision/) تقارير البريد الإلكتروني تحت مفتاح المصفوفة بصيغة الجمع email_verifications. تحتوي المصفوفة على إدخال واحد لكل عقدة تحقق من البريد الإلكتروني في مخطط سير العمل — عادة ما يكون إدخالاً واحداً، ولكن قد تُنتج تدفقات التصعيد عدة إدخالات.
تعني قيمة null أنه لم يتم تشغيل أي خطوة تحقق من البريد الإلكتروني بعد. اجتز عناصر المصفوفة (بدلاً من قراءة email_verifications[0]) عندما يكون بإمكان سير العمل الخاص بك جمع أكثر من عنوان بريد إلكتروني واحد.

المخطط

يوجد المخطط المرجعي الكامل، حقلاً بحقل، في صفحة نماذج البيانات.
يؤدي العنوان غير القابل للتسليم — بسبب بنية غير صالحة، أو نطاق غير موجود، أو سجلات MX مفقودة، أو فشل في تسليم رمز OTP — إلى إنهاء الخطوة كـ Declined مع تحذير الرفض التلقائي UNDELIVERABLE_EMAIL_DETECTED. الاستثناء الوحيد: عندما يكتب المستخدم العنوان بنفسه (لم يتم ملؤه مسبقاً عند إنشاء الجلسة)، يُرجع الإرسال غير القابل للتسليم خطأً مضمناً حتى يتمكن من إعادة المحاولة باستخدام عنوان مختلف بدلاً من رفضه على الفور.

قيم الحالة

أنواع أحداث دورة الحياة

يتم ترتيب lifecycle[] ترتيباً زمنياً. يحتوي كل حدث على type وtimestamp وdetails بالإضافة إلى fee قابلة للفوترة (عند الانطباق): يعتمد payload الخاص بـ details على عائلة الحدث:
  • أحداث الإرسال (EMAIL_VERIFICATION_MESSAGE_SENT، EMAIL_VERIFICATION_RETRY_MESSAGE_SENT) — { status, reason }. تكون قيمة status هي Success أو Retry أو Undeliverable؛ وتكون قيمة reason هي null ما لم يفشل الإرسال (email_can_not_be_delivered، أو unknown للقيم القديمة غير المعروفة).
  • أحداث التحقق (VALID_CODE_ENTERED، INVALID_CODE_ENTERED) — { code_tried, status } مع status بقيمة Approved أو Failed أو Expired or Not Found أو Declined.
  • أحداث الحالة النهائية — null، باستثناء EMAIL_VERIFICATION_DECLINED / EMAIL_VERIFICATION_IN_REVIEW، والتي تحمل { "reason": "<risk code>" } (على سبيل المثال UNDELIVERABLE_EMAIL_DETECTED).
تسجل عمليات الإرسال ذات status بقيمة Success أو Undeliverable رسوم التحقق من البريد الإلكتروني البالغة $0.02؛ بينما تحمل عمليات إرسال Retry وأحداث التحقق وأحداث الحالة دائماً fee: 0.

التطابقات عبر الجلسات

تسجل مصفوفة matches[] العنوان نفسه في عمليات التحقق من البريد الإلكتروني المقبولة سابقاً في نفس التطبيق — عبر جلسات KYC وKYB وجلسات API المستقلة — بالإضافة إلى مطابقات قائمة الحظر التي تم تكوينها في قوائم management-api. يتم استبعاد عمليات التحقق التي تشترك في vendor_data للجلسة الحالية (المستخدم النهائي نفسه لا يطابق نفسه)، ويبلغ الحد الأقصى للمصفوفة 5 مدخلات، مرتبة من الأقدم إلى الأحدث. عندما يكون العنوان موجوداً في قائمة الحظر الخاصة بك ولكن لم يتم إدراج أي من الجلسات المتطابقة في قائمة الحظر، يُضاف إدخال تركيبي مع source: "list_entry" (جميع حقول الجلسة تكون null) في بداية المصفوفة.

أمثلة

مقبولة — رمز OTP سليم مع خرق معلوماتي واحد

مرفوضة — عنوان غير قابل للتسليم

ينتهي العنوان المملوء مسبقاً والذي يفشل في التحقق من صحة البنية أو DNS (MX) — أو الذي يتعذر تسليم بريد OTP إليه — على الفور كـ Declined. لا تظهر أي أحداث للتحقق من الرمز لأن الرمز لم يصل إلى المستخدم أبداً.

مرفوضة — صندوق بريد مؤقت مدرج في قائمة الحظر

أكمل المستخدم عملية التحقق عبر OTP، لكن العنوان تطابق مع قائمة حظر البريد الإلكتروني الخاصة بك (رفض تلقائي). تم أيضاً رفع علامة البريد المؤقت — بمستوى information هنا لأن disposable_email_action تُرِك على قيمته الافتراضية NO_ACTION.

ذات صلة

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