
نظرة عامة
يتم إنشاء تقرير التحقق من رقم الهاتف في كل مرة تُشغّل فيها عقدة سير العمل ميزة التحقق من رقم الهاتف. يمثل كل تقرير تحدي OTP واحداً لرقم هاتف واحد، ويتضمن:- رقم الهاتف مقسماً إلى البادئة، والرقم الوطني، والصيغة الكاملة وفق E.164، بالإضافة إلى رمز الدولة وفق ISO واسم الدولة.
- البيانات الوصفية لشركة الاتصالات (
name،type) التي تم تحديدها من شبكة الوجهة. - علامات المخاطر المنطقية (
is_disposable،is_virtual) المستمدة من تحليل نوع الخط. - قناة التسليم الفعلية المستخدمة (
verification_method) وعدد محاولات إرسال OTP. - سجل
lifecycle[]زمني لكل عملية إرسال، وإعادة محاولة، وحدث تسليم، ومحاولة للتحقق من الرمز. - مصفوفة
matches[]تُظهر ظهور الرقم نفسه في جلسات أخرى — بأي حالة، عبر عمليات التحقق من KYC وKYB والتحقق عبر API المستقل — أو في قائمة الحظر الخاصة بك. - مصفوفة
warnings[]— أحداث المخاطر الصادرة أثناء عملية التحقق (راجع تحذيرات التحقق من رقم الهاتف). - معرّف
node_idيحدد عقدة مخطط سير العمل التي أنتجت التقرير (جلسات V3 فقط).
POST /v3/phone/send/ لتسليم الرمز وPOST /v3/phone/check/ للتحقق من صحة ما أدخله المستخدم. يكون رمز OTP المعلق صالحاً لمدة 5 دقائق من أول عملية إرسال (ولا تمدد عمليات إعادة المحاولة هذه النافذة الزمنية). في جلسات سير العمل، يحصل المستخدمون افتراضياً على محاولتَي إرسال لرمز OTP (phone_max_retries) ومحاولتَي إدخال للرمز (phone_max_check_attempts) — وكلاهما قابل للضبط لكل عقدة سير عمل؛ واستنفاد أي من الحدين يُنهي الخطوة بالحالة Declined مع الرمز VERIFICATION_CODE_ATTEMPTS_EXCEEDED. ويتيح API المستقل للهاتف 3 محاولات لإدخال الرمز لكل عملية تحقق.
أين يظهر في استجابات API
يعيد endpoint القرار (GET /v3/session/{sessionId}/decision/) تقارير الهاتف تحت مفتاح المصفوفة بصيغة الجمع phone_verifications. تحتوي المصفوفة على إدخال واحد لكل عقدة تحقق من رقم الهاتف في مخطط سير العمل — عادةً ما يكون إدخالاً واحداً، ولكن قد تُنتج تدفقات التحقق الإضافي عدة إدخالات.
null أنه لم يتم تشغيل أي خطوة تحقق من رقم الهاتف بعد. كرّر المرور على المصفوفة (بدلاً من قراءة phone_verifications[0]) عندما يمكن لسير العمل الخاص بك جمع أكثر من رقم هاتف واحد.
المخطط
يوجد المخطط القياسي، حقلًا بحقل، في صفحة نماذج البيانات.قيم الحالة
أنواع أحداث دورة الحياة
يتم ترتيبlifecycle[] زمنياً. يحتوي كل حدث على type وtimestamp وdetails ورسم fee قابل للفوترة (عند الاقتضاء):
يعتمد payload الخاص بـ
details على عائلة الحدث:
- أحداث الإرسال (
PHONE_VERIFICATION_MESSAGE_SENTوPHONE_VERIFICATION_RETRY_MESSAGE_SENTوPHONE_VERIFICATION_BLOCKED) —{ status, reason, channel, actual_channel }. تكون قيمةstatusإماSuccessأوRetryأوBlocked؛ وتكون قيمةreasonهيnullما لم يتم حظر الإرسال (invalid_phone_number،repeated_attempts،suspicious،spam،unknown)؛ ويمثلchannelالقناة المطلوبة وactual_channelالقناة التي قامت بالتسليم فعلياً (على سبيل المثال، إرسال عبر WhatsApp رجع تلقائياً إلى SMS كبديل). - أحداث التسليم (
PHONE_DELIVERY_DELIVEREDوPHONE_DELIVERY_UNDELIVERABLE) —{ channel, status }مع كونstatusإماdeliveredأوundeliverable. - أحداث التحقق (
VALID_CODE_ENTEREDوINVALID_CODE_ENTERED) —{ code_tried, status }مع كونstatusإماApprovedأوDeclinedأوFailedأوExpired or Not Found. - أحداث الحالة النهائية —
null، باستثناءPHONE_VERIFICATION_DECLINED/PHONE_VERIFICATION_IN_REVIEWاللذين يحملان{ "reason": "<risk code>" }(على سبيل المثالPHONE_NUMBER_IN_BLOCKLIST).
fee في حدث الإرسال هي السعر الإجمالي لعملية الإرسال تلك: سعر شركة الاتصالات أو WhatsApp بالإضافة إلى رسوم Didit البالغة $0.02، أو رسوم Didit البالغة $0.02 فقط لرمز WhatsApp مُرسل من رقم WhatsApp Business الخاص بك. وتكون هي السعر التقديري حتى يتم تأكيد التسليم، ثم يصبح المبلغ الفعلي المفوتر. عمليات الإرسال ذات الحالة Blocked فقط هي المضمونة بأنها مجانية: حيث تُفرض رسوم أي إرسال آخر عند إنهاء عملية التحقق أو انتهاء صلاحيتها، حتى لو لم يتم تأكيد التسليم مطلقاً أو كانت الرسالة غير قابلة للتسليم. وتحمل أحداث التسليم والتحقق والحالة دائماً fee: 0.
التطابقات عبر الجلسات
يسجلmatches[] الجلسات الأخرى في نفس التطبيق التي ظهر فيها نفس الرقم — عبر عمليات التحقق من KYC وKYB وAPI المستقل، بغض النظر عن حالتها — بالإضافة إلى مطابقات قائمة الحظر المكونة في قوائم Management API. يتم استبعاد الجلسات التي تشارك vendor_data الخاصة بالجلسة الحالية (فالمستخدم النهائي نفسه لا يطابق نفسه)، ويبلغ الحد الأقصى للمصفوفة 5 إدخالات. وعندما يكون الرقم موجوداً في قائمة الحظر الخاصة بك ولكن لا توجد أي جلسة متطابقة مدرجة في قائمة الحظر، يُضاف إدخال تركيبي مع source: "list_entry" (مع تعيين جميع حقول الجلسة إلى null) في بداية المصفوفة.
أمثلة
مقبولة — رمز OTP عبر WhatsApp، مشغّل شبكة الجوال
مرفوضة — رقم VoIP مدرج في قائمة الحظر
أدخل المستخدم رمز OTP صالحاً، لكن إتمام العملية أظهر أن الرقم موجود في قائمة الحظر الخاصة بالتطبيق (رفض تلقائي) واكتشف أن نوع خطه هو VoIP (تُركvoip_number_action على NO_ACTION، لذا يُسجّل كـ information). ولأنه لا توجد جلسة متطابقة مدرجة في قائمة الحظر، يظهر تطابق قائمة الحظر كتطابق list_entry تركيبي.
ذات صلة
- نظرة عامة على التحقق من رقم الهاتف — سلوك الميزة، الأسعار، القنوات المدعومة.
- تحذيرات التحقق من رقم الهاتف — كل رمز مخاطر، والمُشغِّلات التي تؤدي إلى الرفض والإجراءات القابلة للتكوين.
- نماذج البيانات — التحقق من رقم الهاتف — المخطط القياسي حقلاً بحقل.
- API الهاتف المستقل — نقطتا endpoint الخاصتان بـ
POST /v3/phone/send/وPOST /v3/phone/check/. - Management API — القوائم — إدارة قائمة حظر الهواتف التي تغذي
matches[]بـsource: list_entry.