A local checkout timer is a user-experience boundary, not proof that funds cannot arrive later. Network delay, customer authorization timing, provider notification delay, or clock differences can produce verified payment evidence after your application marks the order expired.
Never delete expired payment attempts. Keep their references and expected amount, accept authentic late events into a late_payment_review state, and apply a documented business policy. Inventory availability, service eligibility, duplicate replacement orders, and refund capability determine whether the original order can be honoured automatically.
Design principles
The boundaries that keep this flow reliable
Expiry is not deletion
Retain the order reference, amount, customer-safe contact link, and event history so late evidence can be reconciled.
Use a distinct exception state
Do not silently change expired to paid. A late_payment_review state makes operational policy and reporting visible.
Prevent double benefit
Check whether the customer created and paid a replacement order before honouring the expired attempt.
Implementation workflow
From request to a durable result
- 1
Authenticate payment evidence
Verify the signed event or status response and match tenant, reference, amount, and provider evidence.
- 2
Check related orders
Search for a replacement order, prior fulfilment, refund, dispute, or another payment attempt associated with the same cart.
- 3
Apply merchant policy
Honour when fulfilment remains valid and unique; otherwise queue an authorized refund or support review according to your provider process.
- 4
Tell the customer clearly
Show that payment is under review, provide a stable support reference, and avoid promising a refund timeline you cannot guarantee.
Late-payment state transition
tsif (order.status === "expired" && payment.status === "paid") {
assert(payment.amountPaise === order.expectedAmountPaise);
assert(payment.clientTxnId === order.paymentReference);
await transitionOrder(order.id, {
from: "expired",
to: "late_payment_review",
evidenceId: payment.eventId,
});
// An authorized policy worker decides honour or refund next.
}Production checklist
Verify before going live
- Expired attempts remain queryable
- Late evidence is signature/status verified
- Replacement and duplicate orders are checked
- Honour/refund decision is auditable
- Customer receives a support reference and accurate status
Failure recovery
Late-payment mistakes
Immediate fulfilment after expiry
Inventory or eligibility may have changed. Route through a policy that checks whether the original order remains valid.
Automatic refund without duplicate check
The merchant may fulfil one order and refund another incorrectly. Reconcile the full cart/payment history first.
No customer-visible state
A generic failed page creates disputes. Show that verified payment is under review and provide a traceable reference.
FAQ
Questions developers ask
Can a UPI payment succeed after my countdown ends?
Your application timer and the payment system do not necessarily finalize at the same instant. Treat later verified evidence as an exception, not as impossible.
Should every late payment be refunded?
That depends on merchant policy, provider capabilities, inventory, and whether a replacement order was fulfilled. Make the decision controlled and auditable.
How should the order appear to the customer?
Use a clear under-review state with a support reference until the merchant decides to honour or refund.