Skip to main content

نظرة عامة

بعد إرسال طلب الشحن، استطلع endpoint الحالة حتى تصل المعاملة إلى حالة نهائية. تُعالج API الطلبات عادةً في غضون 5-30 ثانية، وتمر بالحالات PENDING → HANDLING → FULFILLED/REFUNDED.
تحذير حرج: تعامل بشكل صحيح مع جميع قيم الحالة، وخاصةً UNKNOWN_ERROR. لا تُصدر استرداداً فورياً عند ظهور حالة غير معروفة!

API التحقق بالمرجع

GET /v3/mobile/check-ref/:ref - التتبع باستخدام مرجعك

API التحقق بالمعرّف

GET /v3/mobile/check-id/:id - التتبع باستخدام معرّف الشحن

قيم الحالة

فهم كل حالة أمر بالغ الأهمية للتعامل الصحيح:
راجع مرجع API التحقق بالمعرّف للاطلاع على أوصاف تفصيلية للحالات وحالات الاستخدام.

التطبيق الأساسي للاستطلاع

التعامل مع حالات الحالة المختلفة

استطلاع الحالة في الخلفية

للحصول على أداء أفضل، استطلع الحالة في مهام الخلفية:

إعادة الفحص المجدولة لـ UNKNOWN_ERROR

أنشئ مهمة cron يومية لإعادة فحص الطلبات غير المؤكدة:

استراتيجية الاستطلاع المُحسَّنة

استخدم فترات استطلاع ذكية:

أفضل الممارسات

انتظر حتى تُحسم الحالة إلى FULFILLED أو REFUNDED خلال 24 ساعة قبل معالجة الاستردادات.
استطلع الحالة بشكل غير متزامن لتجنب حجب طلبات المستخدمين وتحسين الأداء.
حدد حداً أقصى لمحاولات الاستطلاع (عادةً 60 = 5 دقائق) وأعد جدولة الفحوصات عند الحاجة.
احفظ الحالة في قاعدة بياناتك لتقليل استدعاءات API. استعلم API فقط عندما لا تكون الحالة نهائية.
اعرض دائماً refund_message للمستخدمين كما هو. إنه باللغة العربية ويشرح المشكلة بوضوح.
عند توفر suggested_offers، اعرض هذه البدائل لتحسين معدل التحويل.

الخطوات التالية

استراتيجيات الاستطلاع

تعلّم تقنيات تحسين الاستطلاع المتقدمة

Webhooks

إعداد إشعارات الحالة الفورية بدلاً من الاستطلاع

API قائمة الشحنات

اطلع على جميع معاملات الشحن الخاصة بك

معالجة الأخطاء

مرجع معالجة الأخطاء الكامل