Reading UPI success rates without fooling yourself

Define the denominator first

Decide whether you are measuring attempts, unique orders, authorised payments or captured payments. Each answers a different question. A retry policy that allows three attempts can lift the attempt-level rate while leaving the order-level rate flat.

Write the definition down and keep it for every report. If the definition changes, the trend is not comparable.

Segment before you optimise

Break the number down by rail, app, device, issuer bank, failure code and time window. A hosted page that converts 60% overall may be 70% on Android intent links and 40% on desktop redirects. The average hides the part you can fix.

• Rail: hosted, native collect, intent.
• App: the UPI app that actually opened.
• Device: Android, iOS, desktop.
• Failure: decline, timeout, pending, missing callback.

Count retries correctly

Retries are a recovery mechanism, not a success metric. Count the unique order’s final state, and report retries separately. If a third attempt succeeds, the order succeeded—but the first two failures still describe the buyer experience.

Bound retries at three and stop on a hard decline. Endless retries inflate attempts and delay the final state.

Watch latency and pending orders

Callbacks should arrive within five seconds in the sandbox. If they do not, poll the status rather than declaring failure. Pending orders are not failures; they are unresolved. Report them separately and age them against the cut-off.

A five-step review

1. Freeze the definition.
2. Segment by rail and app.
3. Classify failures by code, not by guess.
4. Change one variable at a time.
5. Re-measure on the same window.

The goal is not a prettier number. It is a shorter list of failure modes you can actually remove.