Skip to main content
POST
Discover Bills

Overview

Asks a biller what a given account currently owes. The response is a transactionId you then poll; when the transaction reaches READY, its bills[] array holds everything that is payable.
200 is an acknowledgement, not an outcome. It means the request was accepted and a transaction was created. The bills arrive later, in the transaction. Never treat this response as “the account owes nothing”.
Discovery does not move money and does not commit you to anything. It is safe to run before you show a customer what they owe.

Request Body

string
required
The biller to query. Exactly one of ADE, SONELGAZ, SEAAL, AADL, Algérie Télécom — accents included.Check List Partners first; an UNAVAILABLE partner answers 503 PARTNER_UNAVAILABLE.
object
required
The account to look up. It must carry exactly one identifier — see Account identifiers below. Zero identifiers, or two, is rejected.
string
required
Your own reference for this discovery. Maximum 100 characters, and unique among your live transactions for that partner.Reusing a ref answers 403 DUPLICATED_REF. It is also how you recover a lost response — see Get Transaction by Reference.

Account identifiers

Send the field that belongs to the partner you are querying. This is also the field the API returns in account on every transaction for that partner. Two richer forms are also accepted where the biller needs more than a single number to identify a bill:
All three fields are required together.
invoice_number up to 20 characters, amount_without_stamp up to 20, ebb_key up to 30.
All four fields are required together.
sub_id exactly 12 characters, period in MM/YYYY format, amount up to 20 characters, pay_key exactly 7 characters.
Accepted for ADE and SEAAL as an alternative to reference. It must be exactly 25 characters.
Exactly one identifier. reference, contractNumber, aadlNumber and electronic_payment_key count as the same slot, as do phoneNumber and phone_number; sonelgaz and ade are each their own slot. Sending none, or sending two, is rejected with 400.

Response

boolean
required
true when the discovery was accepted.
object
required
object
required
string
required
Correlation identifier, also sent as the X-Request-Id response header.

Examples

Success Response

Poll Get Transaction by ID until status is READY, then read bills[]:

Error Responses

The request body did not match the schema.
details lists every field that failed, not just the first. Common causes: a missing ref, a partner that is not one of the five values, an account with no identifier or with two, an electronic_payment_key that is not exactly 25 characters, a phoneNumber that is not a valid Algerian landline.What to do: fix the request. Retrying it unchanged returns the same error.
The identifier is structurally acceptable but not usable for this partner.
What to do: ask the customer to check the number on their bill. This is the error to surface to them; ERR_VALIDATION is one for your logs.
The key was absent or rejected.
A missing header returns MISSING_ACCESS_TOKEN instead, with the same HTTP status.What to do: verify the key with Validate API Key.
You have already used this ref for this partner.
What to do: do not retry with a new ref blindly — you would start a second discovery for the same account. Look the existing one up with Get Transaction by Reference and carry on from its state.
This account was already paid recently, so a new discovery is refused.
What to do: this is a guard against double payment, not a failure. Find the successful transaction in List Transactions and show the customer that receipt.
Another payment for this account has not finished yet.
What to do: wait for that payment to reach a final state, then start again. Do not run both in parallel.
The biller cannot be reached, or is currently switched off.
What to do: refresh List Partners and try again later. No transaction was created and nothing was charged. This response carries no Retry-After; back off on your side.
We could not verify your key in time. Your key is not the problem.
What to do: wait for Retry-After (5 seconds) and retry the same request with the same ref.
The Bill Payment API is in planned maintenance.
What to do: honour Retry-After and retry with the same ref.
Something failed on our side.
What to do: check whether the discovery was created with Get Transaction by Reference before retrying, and send the requestId to support if it persists.

The 200 DZD discovery floor

Bills below 200 DZD are filtered out during discovery and never appear in bills[]. A READY transaction with an empty bills[] therefore means one of two things, and the API does not distinguish between them:
  • the account owes nothing, or
  • everything it owes is below the 200 DZD floor.
Word this carefully for your customers. “No bills are payable right now” is accurate; “you owe nothing” is not.

Preventing duplicate requests

ref makes a discovery safe to retry. If a network error hides the response, look the ref up instead of sending a second discovery.
A good ref is derived from something you already store — your own invoice or order identifier — so you can always reconstruct it. See Discovering bills for a naming recipe.

Status Lifecycle

1

PENDING

The response you just received. The discovery is queued and running.
2

READY

Discovery finished. bills[] is present — possibly empty. Choose a billId and call Pay a Bill.
3

FAILED

The discovery could not complete. error.code explains why: INVALID_ACCOUNT, PARTNER_UNAVAILABLE, BILL_ALREADY_PAID or PAYMENT_DECLINED.
Full status reference →

Best Practices

Check the partner first

A cached partner map lets you hide an unavailable biller before the customer fills in an account number.

Derive the ref, do not invent it

Build ref from your own order identifier so you can always look the transaction up again.

Never assume 200 means empty

The bills arrive in the transaction, not in this response. Poll before you tell a customer anything.

Read fee from the response

Each bill carries its own fee. Do not recompute it in your own code.

List Partners

Check availability first

Get Transaction by ID

Poll for the bills

Pay a Bill

Pay one of them

Get Transaction by Reference

Recover a lost response

Discovering Bills

The full walkthrough

Partners and Accounts

Identifier rules per partner