Skip to main content
POST
اكتشاف الفواتير

نظرة عامة

يسأل مُصدِر الفواتير عن المبالغ المستحقة حاليًا على حساب معيّن. الاستجابة هي transactionId تستعلم عنه دوريًا بعد ذلك؛ وعندما تبلغ المعاملة الحالة READY، تحتوي مصفوفة bills[] الخاصة بها على كل ما هو قابل للدفع.
200 إقرار بالاستلام، وليس نتيجة. فهو يعني أن الطلب قُبِل وأن معاملة أُنشئت. الفواتير تصل لاحقًا، داخل المعاملة. لا تعتبر هذه الاستجابة أبدًا بمعنى «لا يترتب على الحساب أي مبلغ».
الاكتشاف لا يحرّك أي أموال ولا يُلزمك بشيء. من الآمن تشغيله قبل أن تعرض على العميل ما هو مستحق عليه.

متن الطلب

string
مطلوب
مُصدِر الفواتير المطلوب الاستعلام عنه. قيمة واحدة بالضبط من ADE، SONELGAZ، SEAAL، AADL، Algérie Télécom — مع الحفاظ على العلامات (accents) كما هي.راجع قائمة الشركاء أولًا؛ الشريك الذي حالته UNAVAILABLE يُجيب بـ 503 PARTNER_UNAVAILABLE.
object
مطلوب
الحساب المطلوب البحث عنه. يجب أن يحمل معرّفًا واحدًا بالضبط — راجع معرّفات الحساب أدناه. عدم إرسال أي معرّف، أو إرسال معرّفين، مرفوض.
string
مطلوب
مرجعك الخاص لعملية الاكتشاف هذه. 100 حرف كحد أقصى، وفريد بين معاملاتك النشطة لدى هذا الشريك.إعادة استخدام ref تُجيب بـ 403 DUPLICATED_REF. وهو أيضًا الطريقة التي تستعيد بها استجابة ضائعة — راجع الحصول على المعاملة بالمرجع.

معرّفات الحساب

أرسل الحقل الذي يخص الشريك الذي تستعلم عنه. وهو أيضًا الحقل الذي تُرجعه واجهة API في account في كل معاملة لهذا الشريك.تُقبَل أيضًا صيغتان أكثر تفصيلًا حين يحتاج مُصدِر الفواتير إلى أكثر من رقم واحد لتحديد الفاتورة:
الحقول الثلاثة كلها مطلوبة معًا.
invoice_number حتى 20 حرفًا، وamount_without_stamp حتى 20، وebb_key حتى 30.
الحقول الأربعة كلها مطلوبة معًا.
sub_id من 12 حرفًا بالضبط، وperiod بتنسيق MM/YYYY، وamount حتى 20 حرفًا، وpay_key من 7 أحرف بالضبط.
مقبول لدى ADE وSEAAL كبديل عن reference. يجب أن يكون من 25 حرفًا بالضبط.
معرّف واحد بالضبط. تُحسب reference وcontractNumber وaadlNumber وelectronic_payment_key ضمن الخانة نفسها، وكذلك phoneNumber وphone_number؛ أما sonelgaz وade فلكل منهما خانته الخاصة. عدم إرسال أي منها، أو إرسال اثنين، مرفوض بـ 400.

الاستجابة

boolean
مطلوب
true عندما يُقبَل الاكتشاف.
object
مطلوب
object
مطلوب
string
مطلوب
معرّف الربط، يُرسل أيضًا في ترويسة الاستجابة X-Request-Id.

الأمثلة

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

استعلم دوريًا عن الحصول على المعاملة بالمعرّف حتى تصبح status هي READY، ثم اقرأ bills[]:

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

متن الطلب لم يطابق المخطط.
يسرد details كل حقل فشل، وليس الأول فقط. الأسباب الشائعة: غياب ref، أو partner ليست إحدى القيم الخمس، أو account بلا معرّف أو بمعرّفين، أو electronic_payment_key ليس من 25 حرفًا بالضبط، أو phoneNumber ليس خط هاتف ثابت جزائري صالح.ما العمل: صحّح الطلب. إعادة إرساله دون تغيير تُرجع الخطأ نفسه.
المعرّف مقبول من حيث البنية لكنه غير قابل للاستخدام مع هذا الشريك.
ما العمل: اطلب من العميل التحقق من الرقم المدوّن على فاتورته. هذا هو الخطأ الذي تعرضه له؛ أما ERR_VALIDATION فهو لسجلاتك.
المفتاح غائب أو مرفوض.
غياب الترويسة يُرجع MISSING_ACCESS_TOKEN بدلًا من ذلك، بنفس حالة HTTP.ما العمل: تحقق من المفتاح عبر التحقق من مفتاح API.
سبق أن استخدمت هذا ref مع هذا الشريك.
ما العمل: لا تعد المحاولة بمرجع ref جديد بشكل أعمى — فستبدأ عملية اكتشاف ثانية للحساب نفسه. ابحث عن العملية الموجودة عبر الحصول على المعاملة بالمرجع وتابع من حالتها.
هذا الحساب سُدِّد مؤخرًا بالفعل، لذا رُفض اكتشاف جديد.
ما العمل: هذا حارس ضد الدفع المزدوج، وليس فشلًا. ابحث عن المعاملة الناجحة في قائمة المعاملات واعرض على العميل ذلك الإيصال.
دفعة أخرى لهذا الحساب لم تنتهِ بعد.
ما العمل: انتظر حتى تبلغ تلك الدفعة حالة نهائية، ثم ابدأ من جديد. لا تُشغّل الاثنتين بالتوازي.
تعذّر الوصول إلى مُصدِر الفواتير، أو أنه موقوف حاليًا.
ما العمل: حدّث قائمة الشركاء وأعد المحاولة لاحقًا. لم تُنشأ أي معاملة ولم يُخصم أي مبلغ. هذه الاستجابة لا تحمل Retry-After؛ طبّق التراجع التدريجي من جانبك.
لم نتمكن من التحقق من مفتاحك في الوقت المحدد. مفتاحك ليس هو المشكلة.
ما العمل: انتظر مدة Retry-After (5 ثوانٍ) وأعد إرسال الطلب نفسه بالمرجع ref نفسه.
واجهة Bill Payment API في صيانة مُخطط لها.
ما العمل: التزم بـ Retry-After وأعد المحاولة بالمرجع ref نفسه.
حدث خلل من جانبنا.
ما العمل: تحقق مما إذا كان الاكتشاف قد أُنشئ عبر الحصول على المعاملة بالمرجع قبل إعادة المحاولة، وأرسل requestId إلى الدعم إذا استمرت المشكلة.

حدّ الـ 200 دينار جزائري في الاكتشاف

تُستبعَد الفواتير التي تقل عن 200 دينار جزائري أثناء الاكتشاف ولا تظهر أبدًا في bills[].لذلك فإن معاملة بحالة READY مع bills[] فارغة تعني أحد أمرين، وواجهة API لا تفرّق بينهما:
  • لا يترتب على الحساب أي مبلغ، أو
  • كل ما يترتب عليه يقل عن حدّ الـ 200 دينار جزائري.
صُغ هذا بعناية لعملائك. عبارة «لا توجد فواتير قابلة للدفع حاليًا» دقيقة؛ أما «لا يترتب عليك أي مبلغ» فليست كذلك.

منع الطلبات المكررة

يجعل ref عملية الاكتشاف آمنة لإعادة المحاولة. إذا حجب خطأ في الشبكة الاستجابة، فابحث عن ref بدلًا من إرسال اكتشاف ثانٍ.
المرجع ref الجيد مُشتق من شيء تخزّنه أصلًا — معرّف فاتورتك أو طلبك — حتى تتمكن دائمًا من إعادة بنائه. راجع اكتشاف الفواتير للاطلاع على طريقة للتسمية.

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

1

PENDING

الاستجابة التي تلقيتها للتو. الاكتشاف في قائمة الانتظار وقيد التنفيذ.
2

READY

انتهى الاكتشاف. bills[] موجودة — وقد تكون فارغة. اختر billId واستدعِ دفع فاتورة.
3

FAILED

لم يتمكن الاكتشاف من الاكتمال. يوضّح error.code السبب: INVALID_ACCOUNT أو PARTNER_UNAVAILABLE أو BILL_ALREADY_PAID أو PAYMENT_DECLINED.
مرجع الحالات الكامل →

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

تحقق من الشريك أولًا

خريطة شركاء مخزّنة مؤقتًا تتيح لك إخفاء مُصدِر فواتير غير متاح قبل أن يُدخل العميل رقم حسابه.

اشتقّ المرجع، لا تخترعه

ابنِ ref من معرّف طلبك الخاص حتى تتمكن دائمًا من البحث عن المعاملة مجددًا.

لا تفترض أبدًا أن 200 تعني فارغًا

الفواتير تصل في المعاملة، لا في هذه الاستجابة. استعلم دوريًا قبل أن تخبر العميل بأي شيء.

اقرأ fee من الاستجابة

كل فاتورة تحمل fee الخاص بها. لا تُعِد حسابه في كودك.

Endpoints ذات الصلة

قائمة الشركاء

تحقق من التوفر أولًا

الحصول على المعاملة بالمعرّف

استعلم دوريًا عن الفواتير

دفع فاتورة

ادفع إحداها

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

استعد استجابة ضائعة

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

الشرح الكامل

الشركاء والحسابات

قواعد المعرّفات لكل شريك