A checkout that renders a QR code is only the start of a payment integration. Before customers use it, your team should prove that its server creates the right order, its client opens the right checkout, and its fulfilment logic reacts only to a verified result. This checklist turns those requirements into repeatable tests.
- Create an order from your server.
- Save its gateway ID and exact payable amount.
- Open the hosted checkout on phone and desktop.
- Check the result with the authenticated status API.
- Run fulfilment exactly once.
Test server-side order creation first
Use a controlled product or invoice from your backend and calculate its price on the server. Send the create request with your merchant API key, then save the returned Trust Gateway order ID, requested amount, returned payable amount and expiry beside the local purchase. A browser bundle must never contain the private key.
Check invalid input deliberately: missing amount, malformed request, an unavailable receiver route and an expired API key should produce safe errors in your application. Your customer-facing page should not expose stack traces, provider credentials or raw database messages. See the create-order reference for the current request and response shape.
Test the hosted checkout in both environments
Open one controlled checkout on a phone and one on a desktop. On phone, verify the supported app handoff; on desktop, scan the QR from a second device. Confirm that the receiver and exact amount shown to the payer match the saved order. A QR image by itself is not proof that the right order will be fulfilled.
Test an unpaid visit too. Open checkout, return to your site without paying, refresh the return page, and confirm that the local purchase remains pending. A redirect, an app launch or a “payment submitted” client event must not unlock content or ship an item.
Exercise each order state
For a controlled successful payment, query GET /api/v1/orders/status/:order_id from your server and compare the authenticated result to the stored order ID and payable amount. Then run the local fulfilment operation. Refresh the page and query again; the same sale must remain fulfilled once, not create another licence, balance credit or shipment.
Also test pending and expiry paths. A pending order should stay visible for review without telling a buyer to pay again. An expired request should not be recycled. When a customer needs another attempt, create a new order only after checking the original record. Read the payment status lifecycle for state-handling guidance.
Test concurrent equal-value payments
Create two orders for the same product price near the same time. Each should preserve its own gateway ID and returned exact payable amount. Reconcile any completed payment to the order that your application saved; never use only a product price, customer name or generic notification to decide which buyer receives access.
This test exposes a common production mistake: a global “last payment” flag that can credit the wrong user when two people pay together. The correct local update is attached to one gateway order and is atomic. The reconciliation guide explains the records to retain.
Keep a release record
Record the date, test order references, route used, expected result and observed result for every release. Do not record secrets in that note. If you change receiver routing, checkout branding, callback handling or fulfilment code, repeat the controlled test before enabling the change for customers.
A small release checklist prevents a much larger support queue. For a deeper matrix covering device, expiry and duplicate cases, use the checkout release test matrix. Your final production rule stays simple: fulfil only after the merchant server verifies the exact saved order.