Skip to main content
GET
التحقق من الحالة بالمعرّف

نظرة عامة

يُرجع حالة شحن هاتف محمول باستخدام topupId المُرجع في استجابة إرسال الشحن.
إذا حددت ref عند إرسال الشحن، يُفضَّل استخدام check-by-ref إذ يعتمد على معرّفاتك الخاصة.

المعلمات

string
مطلوب
المعرّف الداخلي للشحن المُرجع في استجابة send-topup

الاستجابة

boolean
مطلوب
true إذا تم العثور على الشحن وإرجاع حالته
object
مطلوب

قيم الحالة

إذا رأيت UNKNOWN_ERROR، لا تسترد الأموال فورًا ولا ترسل الشحن مجددًا. تحقق من الحالة مرة أخرى بعد 24 ساعة. غالبًا ما تُكمل العملية في النهاية.

الأمثلة

مثال على الاستجابة — تم التنفيذ (FULFILLED)

مثال على الاستجابة — مُسترَد (REFUNDED)

مُسترَد مع عروض مقترحة

عندما لا يتطابق كود الخطة مع نوع رقم الهاتف، ستتلقى بدائل مقترحة:
ملاحظة: suggested_offers مصفوفة ويمكن أن تحتوي على عدة عناصر، مثلاً عند إرسال خطط GETMENU.

استراتيجية الاستعلام

مزامنة API مع قاعدة بياناتك

1

ابدأ الاستعلام

ابدأ التحقق من الحالة فور إرسال الشحن. يمكنك ضبط interval كل 5-10 ثوانٍ على واجهتك للتحقق من الحالة. عند الوصول إلى FULFILLED أو REFUNDED أو UNKNOWN_ERROR، أوقف الاستعلام.
2

فترة الاستعلام

تحقق كل 5-10 ثوانٍ طالما الحالة PENDING أو HANDLING.
3

معالجة النتيجة

حدّث الطلب بناءً على الحالة النهائية

مثال الاستعلام الكامل

معالجة UNKNOWN_ERROR

الاستطلاع مع Backoff الأسي

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

تخزين الحالة مؤقتاً

خزّن الحالة في قاعدة البيانات لتقليل استدعاءات API. استعلم من API الخاصة بنا فقط عندما لا تكون الحالة نهائية (PENDING/HANDLING).

أوقف عند الحالة النهائية

لا تستمر بالاستعلام بعد FULFILLED أو REFUNDED أو UNKNOWN_ERROR

حماية من المهلة الزمنية

حدد حداً أقصى لمحاولات الاستعلام (عادة 60 = 5 دقائق)

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

تعامل مع أخطاء الشبكة بمنطق إعادة المحاولة

أظهر الرسائل بالعربية

أظهر دائماً refund_message للمستخدمين — وهي بالعربية وتشرح المشكلة

عرض بدائل

عند وجود suggested_offers، حدّث واجهتك لإظهار هذه الخطط بدلاً من جميع الخطط

معالجة الاسترداد

سيُضاف refund_message (رسالة باللغة العربية) إلى عملية الشحن، ويجب عرضه كما هو للعميل.أمثلة على السيناريوهات:

رقم هاتف خاطئ

إذا أدخل العميل رقم هاتف خاطئ:

عدم تطابق الخطة

عند إرسال PREPAID_DJEZZY إلى رقم فاتورة (postpaid):

مصفوفة suggested_offers

تُظهر المصفوفة suggested_offers الخطط الصحيحة لرقم الهاتف. حدّث واجهة تطبيقك لعرض هذه الخطط الجديدة بدلاً من عرض جميع الخطط.
مصفوفة suggested_offers يمكن أن تحتوي على عدة عناصر، خاصة عند إرسال طلبات GETMENU.

الاختبار في بيئة Sandbox

فعّل وضع Sandbox من صفحة الإعدادات لاختبار الطلبات دون التأثير على رصيدك.جميع العمليات ستحاكي عملية حقيقية:
1

السير الطبيعي

أي رقم هاتف عادي:
  • أول 5 ثوانٍ: الحالة PENDING
  • أول 15 ثانية: الحالة HANDLING
  • ثم: الحالة FULFILLED
بعد دمج سير FULFILLED، انتقل لاختبار الحالات الأخرى.
2

اختبار الاسترداد مع رسالة

الهاتف: 0600000001اختبار حالة REFUNDED مع refund_message يجب عرضه للعميل
3

اختبار الاسترداد مع اقتراحات

الهاتف: 0600000002اختبار حالة REFUNDED مع refund_message وsuggested_offers
4

اختبار الخطأ غير المعروف

الهاتف: 0600000003اختبار حالة UNKNOWN_ERROR للتأكد من صحة منطق cron job اليومي

Endpoints ذات الصلة

التحقق من الحالة بالمرجع

البحث باستخدام مرجعك الداخلي

إرسال الشحن

إرسال شحن هاتف محمول