Before You Share a Payment Link: A Trust Gateway Checkout Test Matrix

A checkout is ready when a customer can understand the payment, complete it, and receive the correct business outcome. A good screenshot or a successful order-create response only covers part of that journey. Use this release matrix after changing a receiving connection, integration, return URL or checkout branding.

1. Define a controlled test purchase

Use a merchant account and receiving connection you control. Choose a small permitted amount and a product or service that will not accidentally trigger a real shipment. A live UPI payment moves real money: do not assume that a page named “test” or a temporary payment link provides a sandbox. If you test only with mocked responses, label the result as a UI test rather than a verified payment.

Record the browser, device, timestamp and gateway order ID for every attempt. Avoid storing API keys, account passwords or customer banking credentials in the test report. Keep the business order ID in your own application so you can distinguish a new checkout attempt from a new purchase.

2. Check identity and amount before approval

Open the checkout as a customer would, ideally in a browser without your merchant-dashboard login. Confirm that the business name and logo are recognizable, the amount is readable, and the timer has a clear meaning. A branding image that works only in your signed-in browser should fail this check; use a stable public image URL instead.

Scan the QR and compare the receiver and amount inside the UPI app with the intended account. If a FamPay order includes a matching adjustment, use the exact payable total shown for that order rather than substituting the original requested amount. Keep both values in your test record. The branding guide explains why display identity and receiving identity are separate settings.

3. Exercise the two device paths

Scenario	Action	Expected evidence
Desktop checkout	Scan with a second device	QR is readable and shows the expected payment details
Phone checkout	Tap Open UPI app	A supported app handles the request; launching it does not mark the order paid
Saved QR	Use Save QR	An image downloads or a fallback download link appears
Narrow screen	Open at a small viewport	Amount, controls and help remain usable without horizontal scrolling

A device without a compatible UPI handler may not open a payment app. Record that behaviour and ensure your customer instructions still make the QR path understandable. Keep the QR's clear border intact; a logo or decorative effect placed over its modules can make a visually attractive code harder to scan.

4. Test refresh and returning from the app

Refresh while the order is pending and record whether you remain on the same order. The current hosted payment-link flow attempts to reuse a saved, unexpired pending session in the same browser. That storage is local to the browser; a different device, cleared storage or private session can create another attempt. Do not treat a shared link as a universal lock against duplicate purchases.

Return from the payment app and leave the checkout open. Trust Gateway listens for a payment update and also checks order status periodically while pending. The browser should not show success just because the customer tapped the payment button. An interrupted network connection is also not evidence that a payment failed. Reconnect and check the existing order before starting another payment.

5. Cover expiry and uncertain outcomes

Let a separate unpaid test checkout reach expiry. Confirm that the interface stops presenting it as an ordinary fresh payment request once the server reports expiry. A countdown reaching zero and a server-verified terminal status are different events. The current FamPay flow can temporarily continue checking an on-time payment after the QR times out.

If a test enters a review state, the application should preserve the order reference and avoid fulfilment until the ambiguity is resolved. Where the manual UTR form is available, entering a number must trigger verification rather than directly granting success. Do not submit another customer's receipt or reuse a previously accepted payment as a test shortcut. Read the status lifecycle guide for the meaning of the visible states.

6. Verify the business outcome once

For a controlled successful payment, check three records: the receiving account evidence, the verified gateway order status, and your own application's fulfilment record. Returning to a success URL is navigation, not payment authentication. Your backend should check the documented payment data before granting access, marking an invoice paid or dispatching goods.

Then reload your return page and process a repeated notification in a controlled integration test. The same paid order should not issue the product twice. The idempotency guide covers that handler pattern; the webhook setup guide explains the configuration. Test both the notification path and your recovery path when notification handling is temporarily unavailable.

7. Keep a release record and act on failures

Use a simple record with scenario, order reference, expected result, actual result and follow-up owner. A failed logo load is a presentation issue; a wrong receiving account or fulfilment without verified payment is a reason to stop sharing the checkout until corrected. Keep those priorities explicit so cosmetic work does not hide a payment-flow defect.

After a route change, repeat the receiving-account and end-to-end checks with a new order. After a visual change, repeat scanning, narrow-screen and help-form checks. After backend changes, repeat verification and duplicate-delivery checks. This gives each release evidence appropriate to what changed, without requiring customers to discover regressions for you. Start with the current API documentation whenever a test depends on a payload or authentication detail.