Reconciliation means answering a basic question reliably: which paid gateway order belongs to which business sale? It matters for a freelancer selling services, a small shop shipping products, and a software team granting account access. The safest process connects three separate records instead of treating a notification or screenshot as the complete answer.
- Your business order or invoice.
- The Trust Gateway order and exact payable amount.
- The receiving account’s payment evidence.
Keep three records for every attempted payment
Your application should create a local purchase first. It then creates a Trust Gateway order from the server and stores the returned order_id, requested amount, exact payable amount, receiver route and creation time. The receiving account provides a separate financial record once money arrives. Each record answers a different question; none should silently replace the others.
| Record | Useful fields | Decision it supports |
|---|---|---|
| Business sale | Invoice, customer, product, fulfilment state | What should be delivered |
| Gateway order | Order ID, exact payable amount, current status | Which checkout was requested |
| Receiving evidence | Credit amount, time, available transaction reference | Whether money appears to have reached the receiver |
Save the mapping at creation time. Trying to reconstruct it later from a product price or a customer name creates ambiguity, especially when several buyers pay the same amount. The amount validation guide explains why the saved exact payable amount matters.
Run a daily review in a predictable order
Start with newly created orders, then group them by their current authenticated status. Confirmed orders can be compared with the local sale and fulfilled once. Pending orders should remain open for the defined review window. Expired or cancelled orders should not be reused; if a buyer still needs to pay, issue a fresh request after checking whether the original order has any matching credit.
When a payment route is unavailable, stop new checkout creation on that route rather than allowing more ambiguous orders to accumulate. Preserve its earlier order records for investigation. The receiver availability runbook provides a safe pause-and-resume process.
Do not match money by amount alone
Two ₹499 payments can be made within minutes. The same amount might also represent different products, renewals or repeat attempts from the same customer. Match a payment only after comparing the saved gateway order, exact payable amount, time window and any available receiving-side record. If the evidence is incomplete, leave the purchase pending and investigate; a wrong fulfilment can be harder to fix than a short delay.
A payer may send a transaction reference or receipt. Store only the limited information your policy permits, protect it in operational logs, and treat it as a clue. Do not make a customer-entered UTR or screenshot a universal “mark paid” button. It needs to agree with the merchant-controlled records before it changes a purchase state.
Make fulfilment a one-time state change
When an order is verified, update the local purchase from unpaid to fulfilled atomically. That update can grant one software licence, send one course enrolment, create one shipment task or extend one subscription. If the status endpoint is checked again, return the existing result rather than delivering a duplicate benefit.
This protects against normal events such as page refreshes, webhook retries and support rechecks. It also gives your team an audit trail: order created, verified, fulfilled, and any manual review decision. For API-side details, read payment webhooks and status API.
Handle exceptions without hiding them
Use clear internal states such as pending review, confirmed, expired and manually reconciled. A manually reconciled order should record who made the decision, when, and which merchant-side evidence was used. Never overwrite the original gateway state just to make a dashboard look complete.
If a confirmed credit cannot be linked safely to a local purchase, keep it in an exception queue. If a local order remains pending but no matching credit is found, communicate that the original request is being checked and do not ask the buyer to make a second payment immediately. This pattern prevents duplicate collection and gives support a repeatable response.
A small-team reconciliation checklist
- Export or review open business purchases once each day.
- Check their saved Trust Gateway order statuses from the merchant side.
- Compare verified results with receiving-account evidence.
- Fulfil each local purchase exactly once.
- Keep unmatched credits and pending orders in a named review queue.
- Review route changes and low-value controlled tests before routing live orders again.
Good reconciliation is deliberately boring: each record has a role, and exceptions remain visible. Use the create-order reference to save the right fields from day one and the broader reconciliation checklist for an operational template.