Skip to main content
GET
Download Receipt

Overview

Streams the biller’s receipt for a paid bill. This is the only Bill Payment endpoint that does not return JSON on success — the response body is the raw file. Receipts exist only for transactions whose status is SUCCESS. Anything else — a transaction still in flight, a failed one, a refunded one, one that belongs to another partner — answers the ordinary JSON error envelope with 404 NOT_FOUND.
The receiptUrl on a successful transaction is exactly this endpoint. It still needs your X-Access-Token header, so it is not a link you can give to a customer or embed in an email. Download the bytes, store them, and serve them from your own system.

Path Parameters

string
required
The transaction identifier. A 24-character lowercase hexadecimal string, from Get Transaction by ID or from any list.

Response

On success the body is the file itself. Read the response headers to know what you received.
header
required
The media type of the file: application/pdf, image/png or image/jpeg. Anything we cannot identify is served as application/octet-stream.Always branch on this header rather than assuming a PDF.
header
required
attachment; filename="..." — the suggested file name, with the extension that matches Content-Type.
header
required
The size of the file in bytes.
header
required
private, max-age=86400. The receipt belongs to one partner; never cache it in a shared or public cache.
header
required
nosniff.
header
required
Correlation identifier for this request. There is no JSON body on success, so this header is the only place it appears — log it.

Examples

Each sample checks the status before writing anything, and takes the file extension from the response rather than assuming one.

Success Response

The body is binary. The headers look like this:

Error Responses

Errors are returned as JSON, in the same envelope as every other endpoint.
The key was absent or rejected.
What to do: verify the key with Validate API Key.
Either the transaction is not yours in this environment, or it has no receipt.
A receipt exists only once a payment has reached SUCCESS. Downloading while the transaction is PROCESSING returns this, and so does a FAILED or REFUNDED transaction — neither has a receipt because no payment was completed.What to do: read the transaction first, and download only when status is SUCCESS and receiptUrl is present.
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. Downloading is safe to repeat.
The receipt could not be read.
What to do: retry once, then contact support with the requestId. The payment itself is unaffected — the transaction is still SUCCESS.

Downloading at the right moment

Fetch the receipt as soon as a payment reaches SUCCESS, in the same step that records the success on your side.
Store the bytes, not the URL. receiptUrl requires your API key, so a stored link is useless to your customer and dangerous to share.

Best Practices

Download once, store forever

Keep the receipt with your own order record. It is the document a customer dispute is settled with.

Read Content-Type

The receipt is a PDF or an image depending on the biller. Take the extension from the header.

Never expose the URL

Serve receipts from your own system, behind your own authentication.

Pair it with operationId

The receipt is the document; operationId is the reference. Store both.

Get Transaction by ID

Where receiptUrl and operationId appear

List Transactions

Find everything paid in a period

Pay a Bill

The payment that produced it

Receipts and Reconciliation

Storing and reconciling receipts