UPI Checkout Production Test Cases Before Go-Live

A checkout is not production-ready because a QR appeared or a payer app opened. The complete system includes server pricing, order creation, customer navigation, authenticated payment evidence, database state, fulfilment, recovery, and support. Test every boundary before real customers become your QA team.

Start with a dedicated test-data convention. Give each case a recognizable order prefix, expected amount, environment, tester, and cleanup owner. Never place live secrets in screenshots, browser tools, shared spreadsheets, or test reports.

Order Creation Tests

Test the backend before testing payment presentation:

Case	Expected result
Valid cart and unique reference	One pending local order and one payment attempt
Browser changes the amount	Backend ignores it and recalculates the trusted total
Missing or malformed input	Clear 4xx response; no partial order
Create request times out	Retry reuses the same client_txn_id
Same reference submitted concurrently	Database uniqueness prevents two attempts
Gateway rejects the request	Local order remains recoverable and is not shown as paid

Store the expected amount before returning customer-safe payment data. Money should use integer minor units inside your application so floating-point rounding cannot change comparisons. Follow the Dynamic UPI QR API guide for the server-owned order sequence.

Customer Surface Tests

Test real device classes, not only a wide desktop browser:

• Mobile browser with at least one compatible payer app
• Mobile browser where app launch fails or no compatible app is available
• Desktop or laptop using a second device to scan
• In-app browser with constrained navigation
• Slow connection during order creation and status refresh
• Keyboard navigation, zoom, high contrast, and screen-reader labels

The page should show merchant identity, exact payable amount, a short order reference, and one clear next action. A QR on desktop should remain scannable at zoomed layouts. A mobile Intent failure should keep the customer on the same order and provide a fallback; it should not silently create another payment attempt.

Verification Tests

Prove the payment boundary with controlled events:

1. Valid signed success for the expected order and amount.
2. Missing signature, modified body, and stale timestamp.
3. Authentic event for an unknown order.
4. Authentic event with a different amount.
5. Same authentic event delivered twice and concurrently.
6. Final paid order receiving a later stale failed result.
7. Webhook accepted but downstream fulfilment temporarily unavailable.

The valid event should create one durable state transition and one fulfilment effect. Invalid or mismatched events must not change the order. Use the signed webhook guide and duplicate-event guide for exact controls.

Failure and Recovery Tests

Disconnect one dependency at a time. Make the webhook route return 500, pause the fulfilment worker, delay the status response, and simulate a lost acknowledgement after database commit. Restore the dependency and confirm that recovery uses the original order and event identity.

Test customer-facing states too. Pending must not be styled as failed. Expired must explain whether the checkout attempt or reservation expired. If a payment succeeds late, route it through an explicit late-payment policy rather than overwriting order state. The payment-state UX guide provides copy and transition guidance.

Launch Evidence

Create a compact approval record containing:

• Application version and environment
• Test order and event references
• Device/browser matrix results
• Valid, invalid, duplicate, and mismatch outcomes
• Webhook response code and latency
• Database state and fulfilment evidence
• Recovery result for each injected failure
• Known limitations and accepted owner
• Rollback or checkout-disable procedure

Do not include complete secrets, UPI PINs, OTPs, or unnecessary customer identifiers. A production approval should be repeatable: another engineer should be able to read the evidence and understand exactly why the checkout is safe to launch.