List Transactions
Bill Payment
List Transactions
Page through your bill discoveries and payments
GET
List Transactions
Overview
Returns your Bill Payment transactions, newest first. Use it for reconciliation, for a history screen, and for finding a transaction when you have lost its identifier and its reference. The list is scoped to your own account and to the environment of the key you send: a sandbox key never sees production transactions, and vice versa.data is a plain array of transaction objects. The counts live in meta: total, limit and offset.Query Parameters
string
Filter by status. One of
PENDING, READY, PROCESSING, SUCCESS, FAILED, REFUNDED, UNKNOWN.string
Filter by biller. One of
ADE, SONELGAZ, SEAAL, AADL, Algérie Télécom.string
Only transactions created on or after this instant. An ISO 8601 date or date-time, for example
2026-08-01 or 2026-08-01T00:00:00Z.string
Only transactions created on or before this instant. Same format as
from.integer
default:"20"
Page size, between 1 and 100.
integer
default:"0"
How many transactions to skip. Zero or more.
Response
boolean
required
true when the page was returned.array
required
An array of transaction objects, newest first. Each entry has exactly the shape documented on Get Transaction by ID — including the rule that
bills, selectedBill, receiptUrl, operationId and error appear only in the statuses where they are meaningful.An empty array means no transaction matched.object
required
string
required
Correlation identifier, also sent as the
X-Request-Id response header.Examples
Success Response
Error Responses
400 — Validation error
400 — Validation error
A filter value was not accepted.Common causes: a status or partner outside the allowed set, a
from or to that is not an ISO 8601 date, a limit above 100 or below 1, a negative offset.What to do: fix the query string. Values are case-sensitive.401 — Missing or invalid access token
401 — Missing or invalid access token
Paging through a period
meta.total is the count for the filters you sent, so you can page until you have seen all of it. Keep the page size modest and the window bounded.
New transactions are created while you page. For reconciliation, always bound the window with
from and to so the result set cannot grow underneath you.What the list contains
Both discoveries and payments appear here.type tells them apart:
type: "discovery"— a lookup that has not been paid. ItsstatusisPENDING,READYorFAILED.type: "payment"— a discovery that a payment was submitted against. ItsstatusisPROCESSING,SUCCESS,FAILED,REFUNDEDorUNKNOWN.
payment in place, keeping its transactionId and its original ref.
Best Practices
Bound every query
Always send
from and to for reconciliation. An unbounded list grows with your business.Reconcile on SUCCESS and REFUNDED
Those two statuses are where money moved.
FAILED never moved any.Do not poll this endpoint
To follow one transaction, poll it by identifier. Listing repeatedly is slower and heavier for both sides.
Read meta.total
It is the count for your filters, and the only way to know whether another page exists.
Related Endpoints
Get Transaction by ID
The full transaction object
Get Transaction by Reference
Look up by your own
refDownload Receipt
Proof for a paid transaction
Receipts and Reconciliation
A daily reconciliation routine

