Reconcile bill payment orders with API transaction records
Compare local orders, RizPay purchases and customer payment records, revisit unresolved transactions and investigate differences without creating new purchases.
Already registered? Open API settings and follow the business-access steps. Sandbox purchases do not deliver real services.
Reviewed
A customer payment, a bill purchase and a refund are separate records. Reconciliation connects them so you can explain an order without assuming that one successful step means the whole flow completed.
Start with an order-level comparison
Keep your local order ID, stored external reference and returned RizPay transaction ID together. Also retain the reference for the customer's payment to your business. Scope lookups to the correct account and environment before comparing anything.
| Local evidence | Compare with |
|---|---|
| Stored external reference | The transaction's external reference |
| Selected product and recipient | The recorded purchase details available to your integration |
| Expected purchase cost | The returned transaction amount and price breakdown |
| Customer-facing status | The current purchase status |
| Customer collection or refund | Your own payment and accounting records |
Use /account/transactions/YOUR_STORED_REFERENCE for a targeted lookup when the create response was lost. Use /purchases/:id when the purchase ID is already known. A missing result is a reason to investigate the environment, account and reference; it is not automatic permission to submit another purchase.
Process history without losing old pending orders
The production transaction listing supports documented status, category and date filters. Keep the chosen filters consistent across pagination and read pagination.total_pages. Work with a deliberate time window, and deduplicate by transaction ID because the dataset can change while pages are being read.
A window based only on today's creation time will miss yesterday's order that completed today. Keep unresolved local orders in a separate work queue and revisit them until their outcome is established. When reconciling a recent history window, allow overlap and make processing idempotent.
Give differences an owner
Classify mismatches before making changes: missing local response, stale local status, unexpected amount, missing customer refund or delivery-data problem. Each category should have an investigation path and an accountable operator.
A returned failed status does not by itself prove that a payment collected through your own checkout has been refunded. Compare the relevant ledger or payment record before telling the customer their money has returned. Handle a later reversal once, even when several events report it.
Make the job safe to restart
Store progress without treating a cursor as proof that all older orders are resolved. Apply updates transactionally and keep a history of material state changes. Retry reads within a bounded policy; never place a purchase inside a history-repair job.
Test an order that spans midnight, a page repeated after a restart and a successful purchase whose webhook was missed. The result should be a corrected original order, with a clear explanation of any remaining difference.