Skip to main content
GET
Get Transaction by ID

Overview

Returns the complete transaction object — the canonical view of a Bill Payment discovery or payment. Every other Bill Payment endpoint either returns this same object or returns an identifier that points at it. Because discovery and payment are asynchronous, this endpoint is where the real outcome appears. The 200 you received from discover or pay only confirmed that the request was accepted.
A transaction that belongs to another partner returns 404, not 403. The API never confirms that someone else’s transaction exists. The same applies across environments: a sandbox key cannot read a production transaction, and vice versa.

Path Parameters

string
required
The transaction identifier returned by Discover Bills or Pay a Bill.A 24-character lowercase hexadecimal string, for example 68b2f4c1a7d3e9f204c81a55.

Response

boolean
required
true when the transaction was found and returned.
object
required
The transaction object.
object
required
string
required
Correlation identifier, also sent as the X-Request-Id response header. Log it — it is the only thing support needs to trace a request.

Examples

Success Response

A completed payment:
A discovery that finished and found one payable bill:
A payment that was declined and refunded in full:

Error Responses

The X-Access-Token header was not sent.
What to do: send your API key in the X-Access-Token header on every request.
The key was rejected.
What to do: check the key. Do not retry with the same value — this will not resolve on its own.
No transaction with that identifier belongs to your account in this environment.
What to do: confirm the identifier, and confirm you are using the key for the environment the transaction was created in. A malformed identifier also answers 404.
We could not verify your key in time. This is not a verdict on your key.
What to do: wait for the number of seconds in the Retry-After response header, then retry the same request. Never present this to your customer as a credential problem.
The Bill Payment API is in planned maintenance. Every /v3 route answers this.
What to do: honour Retry-After and retry. Reads are safe to repeat.
Something failed on our side.
What to do: retry the read. If it persists, contact support with the requestId.

Status lifecycle

A transaction is created by discover, becomes payable, and then follows the payment through to a final state.
UNKNOWN is not a failure. Never refund your own customer and never retry the payment while a transaction is UNKNOWN — keep polling. It resolves to SUCCESS or REFUNDED.
Full polling strategy →

Fields by status

Only the fields marked below are present. Do not assume a field exists because you saw it in another status. selectedBill and total appear from the moment a bill is selected for payment, so they are absent on a discovery that was never paid.

Best Practices

Branch on status

Treat status as the only source of truth for the outcome. Never infer it from completedAt or from the HTTP status of the original request.

Store the operationId

On SUCCESS, persist operationId and download the receipt. Together they are the proof a customer dispute needs.

Log every requestId

Keep requestId next to your own order identifier. It is the fastest route to an answer from support.

Poll, do not retry

A slow transaction is not a lost one. Poll this endpoint instead of resubmitting the discovery or the payment.

Discover Bills

Start a discovery

Pay a Bill

Pay a discovered bill

Get Transaction by Reference

Look up by your own ref

List Transactions

Filter and paginate history

Download Receipt

Get the proof of payment

Status Polling Guide

A production-grade poller