UPI failure handling: retry UX + ops playbook

Classify failures before you fix them

UPI flows fail in different ways: user abandoned app, bank declined, timeout waiting for confirmation, duplicate request, or success debited but webhook delayed. Your UX and ops responses differ for each. Treating every failure as “try again” creates duplicate charges and support chaos.

Instrument the journey: show explicit states—initiated, awaiting bank, success, failed, pending reconciliation—with a single order reference users can share with support.

Retry UX that actually converts

Offer one-tap retry with the same amount and basket. After two failures, surface alternate rails: different UPI app, netbanking, or card—without resetting seat selection if inventory is still locked. Keep the cart alive with a visible timer so buyers understand urgency.

Avoid blame-heavy copy. “Bank could not confirm” beats “Payment failed” for trust. Link to a short FAQ on pending debits and typical resolution times.

Pending payments and double-debit fear

When status is ambiguous, do not issue tickets until your gateway confirms success. If the user insists money left their account, escalate with transaction ID and timestamp. Finance should have a macro to reconcile against acquirer reports before manual fulfillment.

Throttle rapid retries from the same device or VPA when fraud patterns appear, but do not throttle legitimate users during bank incidents—communicate known outages on status banners.

On-ground and box office fallbacks

Train counters to look up pending orders, cancel stale attempts, and complete payment via POS or cash where policy allows. Never maintain a shadow list of “maybe paid” entries on paper.

Weekly review: failure rate by bank segment, retry success rate, average time-to-ticket after pending, and top error codes. Feed insights back to marketing—bad payment UX looks like weak demand.