Skip to main content

Overview

A payment that reached SUCCESS leaves two pieces of evidence: operationId, the biller’s own reference for the transaction, and the receipt file. Together they settle any dispute a customer raises months later. This step covers downloading and storing both, and a daily routine that proves your ledger and ours agree.

What a success gives you

receiptUrl requires your X-Access-Token header. It is not a link you can email to a customer or embed in a page. Download the bytes and serve them from your own system.

Downloading the receipt

Fetch it in the same step that records the success, and take the file extension from the Content-Type header — a receipt is a PDF or an image depending on the biller.
A receipt exists only for a SUCCESS transaction. Anything else — still in flight, FAILED, REFUNDED, or belonging to another partner — answers 404 NOT_FOUND in the ordinary JSON envelope.

Storing it

1

Download once, at settlement

Fetch the receipt in the same step that marks your order paid. Retrying later is fine, but do not leave it until a customer asks.
2

Store the bytes, not the URL

Put the file in your own object storage, keyed by your order identifier. The API URL needs your key and is useless to anyone else.
3

Store operationId alongside it

The receipt is the document; operationId is the reference. Keep both on the order row.
4

Serve it behind your own authentication

Your customer downloads it from you, not from us.

Reconciling a day

GET /v3/bills/transactions with from and to gives you everything that happened in a window. Bound the window — an unbounded list grows with your business, and a bounded one cannot shift underneath you while you page.

What each mismatch means

Reconcile on SUCCESS and REFUNDED only. A FAILED transaction never moved money, and a PENDING or READY discovery never charged anything.

A daily routine

1

Run once a day, for yesterday

Bound the window with from and to. Yesterday is complete; today is still moving.
2

Match on ref

Your ref is the join key between our transactions and your orders. That is what it is for.
3

Sum SUCCESS and REFUNDED separately

Net movement is SUCCESS totals minus REFUNDED totals. Both belong in your ledger.
4

Carry open transactions forward

Anything still PENDING, PROCESSING or UNKNOWN stays on the list until it resolves.
5

Alert on any mismatch

A reconciliation that finds nothing should be silent. One that finds something should page someone.

Best practices

Store both proofs

operationId and the receipt file. One without the other is half an answer to a dispute.

Reconcile daily, not monthly

A one-day window is small enough to investigate by hand. A month is not.

Never close an open transaction

UNKNOWN and PROCESSING resolve on their own. Carry them forward instead of writing them off.

Serve receipts yourself

Behind your own authentication, from your own storage. Never share the API URL.

Next step

Step 6: Sandbox testing

Reproduce every outcome on demand, then switch to production with confidence

Download Receipt

The endpoint reference

List Transactions

Filters, paging and meta.total

Status Polling

Getting to a final state

Get Transaction by ID

Where operationId appears