AWAITING_USER: المعالجة التلقائية للمعاملات المشبوهة (AR)

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

يحتوي واجهة برمجة تطبيقات مراقبة المعاملات (Transaction Monitoring API) من Didit على حالة رابعة مصممة خصيصًا لهذه الفجوة: AWAITING_USER. بدلاً من الموافقة أو الرفض الثنائي، يمكن للمعاملة التي تم وضع علامة عليها أن تتوقف مؤقتًا، وتطلب إجراءً محددًا من المستخدم - إعادة التحقق من الهوية، أو تقديم إثبات الأموال - وتستأنف تلقائيًا لحظة إتمام ذلك. لا يحدث الاحتكاك إلا حيث توجد المخاطر، ويكلف نفس السعر وهو 0.02 دولار لكل معاملة مثل أي شيء آخر.

يشرح هذا الدليل كيف يعمل مسار AWAITING_USER وكيفية ربطه بسير عملك.

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

• AWAITING_USER هي إحدى حالات المعاملات الأربع - بجانب APPROVED و IN_REVIEW و DECLINED - لذا فإن المعالجة هي نتيجة أساسية، وليست حلاً بديلاً.
• تتوقف المعاملة التي تم وضع علامة عليها مؤقتًا بدلاً من الفشل، وتطلب إجراء تصعيد من المستخدم، وتستأنف تلقائيًا بمجرد إزالة الإجراء.
• يمكن أن يكون التصعيد عبارة عن إعادة KYC، أو تحميل إثبات الأموال، أو أي خطوة تحقق يتم إنشاؤها عبر واجهة برمجة التطبيقات الموحدة /v3/.
• تدفع الـ webhooks الحلقة - يتم تشغيل transaction.status.updated عندما تدخل المعاملة وتغادر AWAITING_USER.
• توجد نفس الحالة في إدارة الحالات، بحيث يمكن للمحلل نقل تنبيه إلى AWAITING_USER والسماح للمستخدم بإزالته.
• 0.02 دولار لكل معاملة، بدون حد أدنى. يتم فرض رسوم على إعادة KYC أو فحص AML الذي يتم إنشاؤه أثناء المعالجة بسعره المنشور الخاص به.

ماذا تفعل AWAITING_USER

عندما يتم تشغيل قاعدة ما، يقوم المحرك بتعيين حالة. ثلاث من الحالات الأربع مألوفة: APPROVED تسمح بمرور المعاملة، IN_REVIEW تفتح تنبيهًا للمحلل، و DECLINED تحظرها. الحالة الرابعة، AWAITING_USER، تفعل شيئًا مختلفًا - تعلق المعاملة وتشير إلى أنه يجب على المستخدم فعل شيء قبل أن تتمكن من الحل.

بشكل ملموس: عندما تتجاوز عملية تحويل قاعدة قيمة عالية أو سرعة عالية، يعيد المحرك AWAITING_USER، ويطالب تطبيقك المستخدم بإكمال الخطوة المطلوبة (فحص حيوية جديد، تحميل مستند، إقرار مصدر الأموال)، وتعود جلسة التحقق إلى المنصة. بمجرد إتمام الخطوة، يتم إعادة تقييم المعاملة وتنتقل إلى APPROVED (أو تتصاعد إذا كانت الأدلة الجديدة تجعل الأمور أسوأ). لا يحتاج أي محلل للإشراف عليها.

لماذا يهم ذلك

عمليات الرفض القاطع مكلفة. كل عملية حظر خاطئة إيجابية هي عميل شرعي محبط، وتذكرة دعم، وغالبًا ما تكون حسابًا تم التخلي عنه. لكن تمرير المدفوعات التي تم وضع علامة عليها هو كيف ينتهي الأمر بالشركات في إجراءات التنفيذ. الحل التقليدي - قائمة انتظار المعالجة اليدوية - يتبادل تكلفة بأخرى: وقت المحلل، وبطء الاستجابة، ومعاملة مجمدة لأيام.

AWAITING_USER ينهار هذا التوازن. يقوم المستخدم بالعمل، في تلك اللحظة، عند نقطة الاحتكاك - بالضبط عندما يكون لديهم الدافع لإتمامها لأن معاملتهم الخاصة تنتظر. أنت تكتشف المخاطر، وتحافظ على العميل، ولا تدفع لمحلل لمطاردة مستند. هذا هو الفرق بين التحكم في الامتثال الذي يكلفك العملاء والتحكم الذي يقوم بعمله بهدوء.

تفاصيل تقنية

تأتي المعاملة التي يوجهها المحرك للمعالجة مع حالة AWAITING_USER والقواعد التي أدت إلى تشغيلها:

{
  "transaction_id": "txn_77c9e2",
  "status": "AWAITING_USER",
  "risk_score": 71,
  "triggered_rules": [
    { "name": "High-value transfer — first 30 days", "bundle": "AML/CTF", "action": "CHANGE_STATUS" }
  ],
  "required_action": "PROOF_OF_FUNDS",
  "alert_id": "alrt_5e3f10"
}

تتفاعل مع ذلك عن طريق مطالبة المستخدم وإنشاء خطوة التحقق على واجهة برمجة التطبيقات الموحدة /v3/. عند اكتمال الخطوة، يخبرك الـ webhook أن المعاملة قد انتقلت:

# webhook payload: transaction.status.updated
{
  "event": "transaction.status.updated",
  "transaction_id": "txn_77c9e2",
  "previous_status": "AWAITING_USER",
  "status": "APPROVED"
}

الـ Webhooks. اشترك في transaction.created و transaction.status.updated. يتم تشغيل حدث تحديث الحالة عند دخول المعاملة إلى AWAITING_USER وعند مغادرتها - بحيث يظل دفتر الأستاذ وواجهة المستخدم لديك متزامنين دون الحاجة إلى الاستقصاء.

السعر. 0.02 دولار لكل معاملة. يتم فرض رسوم على خطوة المعالجة نفسها بسعرها المنشور: إعادة KYC بأسعار التحقق من المستخدم، وفحص AML على طرف تم وضع علامة عليه بسعر 0.20 دولار.

حلقة المعالجة، خطوة بخطوة

1. تشغيل قاعدة. تتجاوز معاملة حدًا تقول سياستك إنه يجب معالجته بدلاً من رفضه - على سبيل المثال، أول تحويل عالي القيمة من حساب جديد.
2. توقف مؤقتًا، لا تفشل. يعيد المحرك AWAITING_USER بدلاً من DECLINED، مع الإجراء المطلوب المرفق.
3. مطالبة المستخدم. يعرض تطبيقك خطوة التصعيد - إعادة فحص الحيوية، تحميل مستند، إعلان مصدر الأموال - وينشئ جلسة التحقق.
4. يمسحها المستخدم. يكمل المستخدم الخطوة داخل نفس التدفق الذي كان فيه بالفعل.
5. الاستئناف تلقائيًا. يتم إعادة تقييم المعاملة بالأدلة الجديدة وتنتقل إلى APPROVED - أو تتصاعد إلى IN_REVIEW/DECLINED إذا كانت الأدلة تزيد من المخاطر. يخبرك الـ webhook transaction.status.updated بحدوث التغيير.

نظرًا لوجود نفس حالة AWAITING_USER في إدارة الحالات، يمكن للمحلل الذي يعمل على تنبيه IN_REVIEW أيضًا إعادته إلى المستخدم بدلاً من حله بنفسه - ينتقل التنبيه عبر OPEN → INVESTIGATING → AWAITING_USER ويتم حله بمجرد استجابة المستخدم.

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

• التقنية المالية (Fintech) - يتوقف أول تحويل عالي القيمة من حساب تم إعداده حديثًا لطلب إثبات الأموال بدلاً من حظر العميل.
• العملات المشفرة (Crypto) - يتوقف تحويل خارجي إلى محفظة ذات تعرض مرتفع لطلب إعلان مصدر الأموال قبل التسوية.
• الإقراض (Lending) - تتوقف عملية صرف الأموال التي تشير إلى هوية اصطناعية لطلب فحص حيوية لإعادة KYC.
• الأسواق (Marketplaces) - تتوقف دفعة البائع التي تشير إلى قاعدة السرعة لإعادة التحقق قبل إطلاق الأموال.
• الألعاب الإلكترونية (iGaming) - يتوقف ارتفاع سرعة الإيداع لإجراء فحص متدرج، والذي يعمل أيضًا كنقطة اتصال للألعاب المسؤولة.

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

1. حدد سياسة المعالجة الخاصة بك. في لوحة تحكم الأعمال (Business Console)، حدد القواعد التي يتم توجيهها إلى AWAITING_USER بدلاً من DECLINED، وأي إجراء تصعيد تطلبه كل قاعدة.
2. أرسل المعاملات. POST /v3/transactions/ مع تحرك الأموال، باستخدام transaction_id ثابت و vendor_data يربط كل معاملة بمستخدمها.
3. تعامل مع التوقف المؤقت. عندما تعيد المعاملة AWAITING_USER، اطالب المستخدم وإنشاء خطوة التحقق على واجهة برمجة التطبيقات /v3/.
4. استمع للاستئناف. تفاعل مع transaction.status.updated لتحرير أو تعليق المعاملة بمجرد إزالة المستخدم للخطوة.

نظرًا لأن كل شيء على واجهة برمجة التطبيقات الموحدة /v3/، فإن KYC المعالجة التي تنشئها المعاملة التي تم وضع علامة عليها هي نفس KYC التي تستخدمها لإعداد المستخدمين - منصة هوية واحتيال واحدة، من البداية إلى النهاية.

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

ما هي AWAITING_USER؟

إنها إحدى حالات المعاملات الأربع. بدلاً من الرفض القاطع، تتوقف معاملة تم وضع علامة عليها مؤقتًا وتطلب إجراءً من المستخدم - إعادة التحقق أو إثبات الأموال - ثم تستأنف تلقائيًا بمجرد إتمام المستخدم لذلك.

هل تستأنف المعاملة من تلقاء نفسها؟

نعم. بمجرد إتمام الخطوة المطلوبة، تتم إعادة تقييم المعاملة وتنتقل إلى APPROVED تلقائيًا - أو تتصاعد إذا كانت الأدلة الجديدة تزيد من المخاطر. يتم تشغيل webhook transaction.status.updated عند التغيير.

ماذا يمكن أن تكون خطوة التصعيد؟

أي خطوة تحقق على واجهة برمجة التطبيقات الموحدة /v3/ - فحص حيوية لإعادة KYC، أو إعادة التحقق من المستندات، أو فحص AML، أو تحميل إثبات الأموال.

هل يجب أن يشارك محلل؟

لا. تعمل حلقة المعالجة التلقائية بدون محلل. ولكن توجد نفس حالة AWAITING_USER في إدارة الحالات، بحيث يمكن للمحلل أيضًا إعادة تنبيه إلى المستخدم عندما يختار ذلك.

ما هي التكلفة؟

0.02 دولار لكل معاملة. يتم فرض رسوم على خطوة المعالجة بسعرها الخاص - إعادة KYC بأسعار التحقق من المستخدم، وفحص AML بسعر 0.20 دولار.

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

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