Skip to main content
GET
الحصول على المعاملة بالمعرّف

نظرة عامة

يُرجع كائن المعاملة الكامل — العرض المرجعي لعملية اكتشاف أو دفع في خدمة دفع الفواتير. كل endpoint أخرى في خدمة دفع الفواتير إما تُرجع هذا الكائن نفسه أو تُرجع معرّفًا يشير إليه.ولأن الاكتشاف والدفع غير متزامنين، فإن هذه الـ endpoint هي المكان الذي تظهر فيه النتيجة الحقيقية. أما الاستجابة 200 التي تلقيتها من discover أو pay فقد أكّدت فقط أن الطلب قُبِل.
المعاملة التي تعود إلى شريك آخر تُرجع 404، لا 403. لا تؤكد واجهة API أبدًا وجود معاملة تخص غيرك. وينطبق الأمر نفسه عبر البيئات: مفتاح Sandbox لا يمكنه قراءة معاملة إنتاج، والعكس صحيح.

معاملات المسار

string
مطلوب
معرّف المعاملة الذي أرجعه اكتشاف الفواتير أو دفع فاتورة.سلسلة سداسية عشرية من 24 حرفًا بأحرف صغيرة، مثلًا 68b2f4c1a7d3e9f204c81a55.

الاستجابة

boolean
مطلوب
true عند العثور على المعاملة وإرجاعها.
object
مطلوب
كائن المعاملة.
object
مطلوب
string
مطلوب
معرّف الربط، يُرسل أيضًا في ترويسة الاستجابة X-Request-Id. سجّله — فهو الشيء الوحيد الذي يحتاجه الدعم لتتبع طلب.

الأمثلة

استجابة النجاح

دفعة مكتملة:
عملية اكتشاف انتهت وعثرت على فاتورة واحدة قابلة للدفع:
دفعة رُفضت واستُردّت بالكامل:

استجابات الخطأ

لم تُرسَل ترويسة X-Access-Token.
ما العمل: أرسل مفتاح API الخاص بك في ترويسة X-Access-Token مع كل طلب.
المفتاح مرفوض.
ما العمل: تحقق من المفتاح. لا تعد المحاولة بالقيمة نفسها — فهذا لن يُحل من تلقاء نفسه.
لا توجد معاملة بهذا المعرّف تعود إلى حسابك في هذه البيئة.
ما العمل: تأكّد من المعرّف، وتأكّد من أنك تستخدم مفتاح البيئة التي أُنشئت فيها المعاملة. المعرّف المشوّه يُجيب أيضًا بـ 404.
لم نتمكن من التحقق من مفتاحك في الوقت المحدد. هذا ليس حكمًا على مفتاحك.
ما العمل: انتظر عدد الثواني المذكور في ترويسة الاستجابة Retry-After، ثم أعد إرسال الطلب نفسه. لا تعرض هذا على عميلك أبدًا على أنه مشكلة في بيانات الاعتماد.
واجهة Bill Payment API في صيانة مُخطط لها. كل مسار /v3 يُجيب بهذا.
ما العمل: التزم بـ Retry-After وأعد المحاولة. عمليات القراءة آمنة للتكرار.
حدث خلل من جانبنا.
ما العمل: أعد محاولة القراءة. إذا استمرت المشكلة، تواصل مع الدعم مع ذكر requestId.

دورة حياة الحالة

تُنشأ المعاملة عبر discover، ثم تصبح قابلة للدفع، ثم تتابع الدفعة حتى تبلغ حالة نهائية.
UNKNOWN ليست فشلًا. لا تسترد المال لعميلك ولا تعد إرسال الدفعة أبدًا ما دامت المعاملة UNKNOWN — تابع الاستعلام الدوري. فهي تُحسم إلى SUCCESS أو REFUNDED.
استراتيجية الاستعلام الدوري الكاملة →

الحقول حسب الحالة

الحقول المؤشَّر عليها أدناه هي وحدها الموجودة. لا تفترض وجود حقل لمجرد أنك رأيته في حالة أخرى.يظهر selectedBill وtotal منذ لحظة اختيار فاتورة للدفع، ولذلك فهما غائبان عن عملية اكتشاف لم يُدفع مقابلها قط.

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

تفرّع بناءً على status

تعامل مع status بوصفها المصدر الوحيد للحقيقة بشأن النتيجة. لا تستنتجها أبدًا من completedAt ولا من حالة HTTP للطلب الأصلي.

احفظ operationId

عند SUCCESS، احفظ operationId ونزّل الإيصال. فهما معًا الإثبات الذي يحتاجه نزاع العميل.

سجّل كل requestId

احتفظ بـ requestId بجانب معرّف طلبك الخاص. فهو أسرع طريق للحصول على إجابة من الدعم.

استعلم دوريًا، لا تعد الإرسال

المعاملة البطيئة ليست معاملة ضائعة. استعلم دوريًا عن هذه الـ endpoint بدلًا من إعادة إرسال الاكتشاف أو الدفعة.

Endpoints ذات الصلة

اكتشاف الفواتير

ابدأ عملية اكتشاف

دفع فاتورة

ادفع فاتورة مكتشَفة

الحصول على المعاملة بالمرجع

ابحث بمرجعك ref الخاص

قائمة المعاملات

صفِّ السجل وتصفّحه

تنزيل الإيصال

احصل على إثبات الدفع

دليل الاستعلام الدوري عن الحالة

مُستعلِم دوري بجودة الإنتاج