المدونة · 21 مايو 2026

دورة حياة جلسة KYB: الحالات وWebhooks (AR)

تتبع عملية التحقق من KYB من البداية إلى النهاية — حالات الجلسة، حالات كل ميزة، حالات كيان الأعمال، وwebhooks التي تحافظ على مزامنة سجلاتك — بتكلفة 2.00 دولار لكل شركة.

بواسطة Didit21 مايو 2026تحديث 21 مايو 2026

عملية التحقق من KYB ليست إجابة بنعم/لا واحدة — إنها عملية ذات أجزاء متحركة. قد تتم الموافقة على البحث في السجل فورًا بينما ينتظر التحقق من المستندات إعادة تقديم ويبقى فحص AML للكيان قيد المراجعة بانتظار المحلل. لتكامل KYB بشكل نظيف، تحتاج إلى معرفة الحالة الدقيقة لكل جزء من عملية التحقق، وتحتاج أن يتم تحديث أنظمتك لحظة تغير أي من هذه الحالات. هذا هو الغرض من دورة حياة الجلسة وwebhooks.

توفر واجهة برمجة تطبيقات التحقق من الأعمال (Business Verification API) من Didit آلة الحالة الكاملة: حالة على الجلسة الإجمالية، حالة على كل ميزة، مجموعة منفصلة من الحالات لكيان الأعمال بمجرد إدارته، وwebhooks التي تعمل عند كل تغيير. التكلفة الكاملة للتحقق من الشركة هي 2.00 دولار، ويحدد هذا الدليل دورة الحياة بأكملها — كل حالة، وكل webhook، وواجهة برمجة تطبيقات الإدارة التي تربط كل ذلك ببعضه.

النقاط الرئيسية

ثلاث طبقات من الحالة. عملية التحقق من KYB لها حالة جلسة، وحالات لكل ميزة، وبمجرد إدارتها، حالة لكيان الأعمال.
ثماني حالات للجلسة. NOT_STARTED (لم تبدأ)، IN_PROGRESS (قيد التقدم)، APPROVED (تمت الموافقة)، DECLINED (تم الرفض)، IN_REVIEW (قيد المراجعة)، RESUBMITTED (أعيد تقديمها)، ABANDONED (مهجورة)، EXPIRED (منتهية الصلاحية).
ست حالات للميزات على كل من ميزات KYB الأربع: NOT_FINISHED (لم تنتهِ)، APPROVED (تمت الموافقة)، DECLINED (تم الرفض)، IN_REVIEW (قيد المراجعة)، RESUB_REQUESTED (طلب إعادة تقديم)، AWAITING_USER (في انتظار المستخدم).
ثلاث حالات للكيان تحت الإدارة: ACTIVE (نشط)، FLAGGED (موضع علامة)، BLOCKED (محظور).
Webhooks على كل شيء. status.updated و data.updated (مع session_kind: business) للجلسات؛ business.status.updated و business.data.updated للكيانات المدارة.
واجهة برمجة تطبيقات إدارة كاملة — POST /v3/businesses/create/، GET /v3/businesses/، GET /v3/businesses/{vendor_data}/، PATCH .../update-status/.

ما تغطيه دورة حياة KYB

تنتج عملية التحقق من KYB حالة في ثلاث طبقات، وكل منها تجيب على سؤال مختلف:

الجلسة تجيب على سؤال "كيف تسير عملية التحقق بشكل عام؟"
كل ميزة تجيب على سؤال "أين يقف فحص السجل / AML للشركة / المستندات / الأشخاص الرئيسيين؟"
كيان الأعمال يجيب على سؤال "ما هو الوضع التشغيلي لهذه الشركة في نظامنا الآن؟"

تقرأ كل الثلاثة، وتحافظ على مزامنتها باستخدام webhooks بدلاً من الاستقصاء. تبدأ عملية التحقق كجلسة، وتُحل ميزاتها، وتصل إلى نتيجة إجمالية، ثم — بمجرد أن تبدأ في إدارة الشركة — تحمل حالة كيان أعمال تتحكم فيها مع تغير الظروف.

لماذا يهم هذا الأمر

بدون حالة مفصلة، يتدهور تكامل KYB إلى التخمين: علامة "معلقة" واحدة لا تخبرك شيئًا عن أي فحص يعيق الأمور أو أي إجراء يمكن أن يزيل العائق. مع حالات كل ميزة، يمكنك التوجيه بدقة — اطلب من مقدم الطلب إعادة تقديم مستند، ضع مطابقة AML للكيان في قائمة انتظار لمراجعة المحلل، اطلب من UBO إكمال KYC الخاص به — بدلاً من فشل عملية التحقق بأكملها.

تعتبر webhooks مهمة لأن KYB غير متزامن. بيانات السجل، التعرف الضوئي على المستندات، ونتائج الفحص تصل في أوقات مختلفة، وتستغرق المراجعة البشرية وقتًا أطول. الاستقصاء عن التغييرات مضيعة للوقت وبطيء؛ تدفع webhooks التغيير لحظة حدوثه، بحيث تعكس سجلاتك الواقع دون الحاجة إلى تشغيل وظيفة cron تضغط على واجهة برمجة التطبيقات.

التفاصيل الفنية

يتم إنشاء جلسة KYB مقابل واجهة برمجة التطبيقات الموحدة /v3/ وتقدم حالة دورة حياتها مرة أخرى.

curl -X POST https://verification.didit.me/v3/session/ \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "workflow_id": "your_kyb_workflow_id",
    "vendor_data": "merchant_6601",
    "callback": "https://yourapp.com/kyb/callback"
  }'

يحمل webhook status.updated حالة الجلسة وحالات كل ميزة:

{
  "event": "status.updated",
  "session_kind": "business",
  "session_id": "kyb_3a90f1c2",
  "vendor_data": "merchant_6601",
  "status": "IN_REVIEW",
  "features": {
    "kyb_registry": "APPROVED",
    "kyb_company_aml": "IN_REVIEW",
    "kyb_documents": "RESUB_REQUESTED",
    "kyb_key_people": "APPROVED"
  }
}

حالات الجلسة. NOT_STARTED، IN_PROGRESS، APPROVED، DECLINED، IN_REVIEW، RESUBMITTED، ABANDONED، EXPIRED.

حالات الميزات. كل من kyb_registry، kyb_company_aml، kyb_documents، و kyb_key_people يبلغ عن إحدى الحالات التالية: NOT_FINISHED، APPROVED، DECLINED، IN_REVIEW، RESUB_REQUESTED، أو AWAITING_USER.

Webhooks. للجلسات: status.updated (تغييرات دورة الحياة) و data.updated (البيانات المثرية)، وكلاهما يحمل session_kind: "business". للكيانات المدارة: business.status.updated و business.data.updated.

السعر. 2.00 دولار لكل عملية تحقق من الشركة.

إدارة كيان الأعمال

بمجرد التحقق من الشركة، تصبح كيانًا تديره عبر واجهة برمجة تطبيقات الأعمال:

POST /v3/businesses/create/ — تسجيل كيان أعمال.
GET /v3/businesses/ — قائمة الأعمال المدارة.
GET /v3/businesses/{vendor_data}/ — جلب عمل واحد بواسطة مرجعه vendor_data.
PATCH .../update-status/ — تغيير حالة الكيان.

يحمل الكيان حالته الخاصة، مستقلة عن جلسة التحقق: ACTIVE (في وضع جيد)، FLAGGED (قيد المراجعة لإشارة خطر)، أو BLOCKED (معلق). هذه هي الطبقة التشغيلية — يمكن للشركة إكمال جلسة APPROVED ثم يتم وضع علامة FLAGGED عليها لاحقًا لأن المراقبة كشفت شيئًا. تؤدي التغييرات على الكيان إلى إرسال business.status.updated و business.data.updated حتى تظل الأنظمة التابعة محدثة.

دورة الحياة، من البداية إلى النهاية

تتبع عملية التحقق النموذجية الطبقات بالترتيب. تبدأ الجلسة بحالة NOT_STARTED، وتنتقل إلى IN_PROGRESS مع تشغيل الميزات، وتُحل كل ميزة — السجل APPROVED، المستندات ربما RESUB_REQUESTED حتى وصول تحميل نظيف، AML للشركة IN_REVIEW حتى يزيل محلل المطابقة، الأشخاص الرئيسيون APPROVED. عندما تستقر جميع الميزات، تصل الجلسة إلى APPROVED، DECLINED، أو IN_REVIEW. من هناك، تدخل الشركة الإدارة ككيان ACTIVE، ويمكن أن تنتقل حالتها لاحقًا إلى FLAGGED أو BLOCKED حسب ما تمليه المراقبة المستمرة — يتم دفع كل انتقال إليك بواسطة webhook.

حالات الاستخدام

الأسواق توجه البائعين بدقة: إعادة تقديم مستند، إنهاء KYC لـ UBO، أو تعليق مطابقة AML للكيان — دون فشل عملية الإعداد بأكملها.
منصات التكنولوجيا المالية والبنوك تحافظ على مزامنة سجلات الحسابات الشركاتية باستخدام webhooks بدلاً من الاستقصاء، وتضع علامة أو تحظر الكيانات مع تغير المخاطر.
مزودو الإقراض يتتبعون حالة كل فحص ائتماني ويحدثون وضع المقترض من خلال واجهة برمجة تطبيقات الإدارة.
منصات التشفير B2B تحافظ على دورة حياة قابلة للتدقيق لكل كيان طرف مقابل من التحقق إلى الوضع المستمر.

كيفية التكامل مع Didit

بناء سير العمل. في وحدة تحكم الأعمال، أنشئ سير عمل KYB بالميزات التي تحتاجها.
إنشاء الجلسة. POST /v3/session/ مع workflow_id الخاص بـ KYB ومرجع vendor_data.
الاشتراك في webhooks. تعامل مع status.updated و data.updated (session_kind: business) للجلسات، و business.status.updated / business.data.updated للكيانات المدارة.
إدارة الكيانات. استخدم POST /v3/businesses/create/، GET /v3/businesses/، GET /v3/businesses/{vendor_data}/، و PATCH .../update-status/ للحفاظ على كل شركة ACTIVE، FLAGGED، أو BLOCKED.

نظرًا لأن كل ذلك موجود على واجهة برمجة التطبيقات الموحدة /v3/، فإن نفس نموذج دورة الحياة يمتد عبر KYC والمراقبة وKYB — آلة حالة واحدة متسقة لمنصة الهوية والاحتيال بأكملها.

الأسئلة المتكررة

ما هي حالات جلسة KYB؟

NOT_STARTED، IN_PROGRESS، APPROVED، DECLINED، IN_REVIEW، RESUBMITTED، ABANDONED، و EXPIRED.

ما هي الحالات التي تبلغ عنها الميزات الفردية؟

كل من kyb_registry، kyb_company_aml، kyb_documents، و kyb_key_people يبلغ عن NOT_FINISHED، APPROVED، DECLINED، IN_REVIEW، RESUB_REQUESTED، أو AWAITING_USER.

ما هي webhooks التي يجب أن أشترك فيها؟

للجلسات، status.updated و data.updated (مع session_kind: business). لكيانات الأعمال المدارة، business.status.updated و business.data.updated.

كيف يمكنني تغيير وضع الشركة بعد التحقق؟

استخدم واجهة برمجة تطبيقات الإدارة — PATCH .../update-status/ — لتعيين الكيان إلى ACTIVE، FLAGGED، أو BLOCKED.

ما هي تكلفة التحقق من KYB؟

2.00 دولار لكل شركة للتحقق الكامل — السجل، UBO، المسؤولون، وAML للكيان.

هل أنت مستعد للبدء؟

اقرأ نظرة عامة على التحقق من الأعمال في الوثائق، واطلع على كيفية توافقها مع باقي المنصة في صفحة منتج التحقق من الأعمال، وتحقق من التسعير الشفاف لكل مكالمة في صفحة التسعير. عندما تكون مستعدًا، ابدأ مجانًا — 500 فحص KYC مجاني شهريًا، والتحقق من الأعمال بتكلفة 2.00 دولار لكل شركة.