Discover Bills
Bill Payment
Discover Bills
Start a bill discovery for a partner account
POST
Discover Bills
Overview
Asks a biller what a given account currently owes. The response is atransactionId you then poll; when the transaction reaches READY, its bills[] array holds everything that is payable.
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 inaccount 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:
sonelgaz — invoice form
sonelgaz — invoice form
All three fields are required together.
invoice_number up to 20 characters, amount_without_stamp up to 20, ebb_key up to 30.ade — invoice form
ade — invoice form
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.electronic_payment_key — 25-character key
electronic_payment_key — 25-character key
Accepted for ADE and SEAAL as an alternative to
reference. It must be exactly 25 characters.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
status is READY, then read bills[]:
Error Responses
400 — Validation error
400 — Validation error
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.400 — Invalid account
400 — Invalid account
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.401 — Missing or invalid access token
401 — Missing or invalid access token
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.403 — Duplicate reference
403 — Duplicate reference
You have already used this What to do: do not retry with a new
ref for this partner.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.409 — Bill already paid
409 — Bill already paid
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.
409 — Payment in progress
409 — Payment in progress
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.
500 — Internal error
500 — Internal error
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 inbills[].
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.
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.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.Related Endpoints
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

