Skip to main content
GET
Get Transaction by Reference

Overview

Finds a transaction by the ref you sent when you started the discovery. It returns exactly the same object as Get Transaction by ID. This is the recovery path. When a response is lost to a timeout, a crash or a redeploy, look the ref up — never resend the write.
A ref is unique per partner, not globally. If you reuse the same ref string for two different partners, pass partner as well so the lookup is unambiguous.

Query Parameters

string
required
The reference you supplied when you created the discovery. Maximum 100 characters.
string
Optional. One of ADE, SONELGAZ, SEAAL, AADL, Algérie Télécom. Narrows the lookup to that biller.

Response

Identical to Get Transaction by ID — the full transaction object, wrapped in the standard envelope. See that page for the field-by-field reference and for which fields appear in which status.
boolean
required
true when a transaction was found.
object
required
The transaction object. Full field reference →
object
required
string
required
Correlation identifier, also sent as the X-Request-Id response header.

Examples

Success Response

Error Responses

ref was missing, too long, or partner was not a known value.
What to do: send ref as a query parameter, URL-encoded, at most 100 characters.
The key was absent or rejected.
What to do: verify the key with Validate API Key.
No transaction with that ref belongs to your account in this environment.
What to do: after a failed write, a 404 here is the proof that the request never landed — it is safe to send it again with the same ref. Check too that you are using the key for the environment the transaction was created in.
We could not verify your key in time, or the API is in planned maintenance.
What to do: honour the Retry-After header (5 seconds) and retry. A lookup is always safe to repeat.

Recovering from a lost response

The pattern is the same for a discovery and for a payment: if the write failed in a way you cannot explain, ask what the ref resolved to before you send anything again.
A 404 from this endpoint is only meaningful when you are asking about a ref you definitely sent. Never use it to decide that a payment did not happen when the discovery ref is what you looked up — a payment lives on the same transaction as its discovery, under the discovery’s ref.

Best Practices

Look up, do not resend

Every timeout and every DUPLICATED_REF is answered here, not by a second write.

Pass the partner

It costs nothing and removes any ambiguity when the same ref string exists for two billers.

Store the ref with your order

A ref you cannot reconstruct is a transaction you cannot recover.

Poll by ID once you have it

Use this endpoint to recover, then poll by transactionId — one fewer parameter to get wrong.

Get Transaction by ID

The full transaction object

List Transactions

Filter and paginate history

Discover Bills

Where a ref is created

Status Polling

A production-grade poller