Skip to content
FintechConfidentialFlagship

UPI Payment Journey

UPI ID entry, validation, transaction status, confirmation, failure and retry — designed for clarity and calm under real payment anxiety.

Client

Financial Services Client (confidential)

Role

UX/UI Designer — payment states, validation, error and recovery design.

Platform

Mobile · Web · Voice + Visual UI

Confidentiality: Client identity and transaction data are confidential. Error copy below is UX copy exploration, not shipped copy.

UPIPaymentsFintechError States
OverviewContextJourneyUX DecisionsInteractionEdge CasesScreensLearnings

01Overview

The UPI payment journey: entering a UPI ID, validation, amount confirmation, async transaction status, success — and honest, calm failure states with recovery. Designed for the anxiety of moving money.

02Context

Collections and bill payments moved to UPI because it is instant and free. But UPI is asynchronous: confirmation can take seconds or minutes, and failures have many quiet flavours. Users needed to know exactly what happened to their money at every moment.

03User Journey

Payment journey

  1. 01

    UPI ID entry

    Single focused field, keyboard optimised, inline validation.

  2. 02

    Validation

    Instant check with clear feedback before any amount entry.

  3. 03

    Amount + confirm

    The amount and payee in an unambiguous review card.

  4. 04

    Transaction status

    Pending states while the provider confirms — with a timer, not silence.

  5. 05

    Success / failure

    Explicit terminal states with reference numbers or clear recovery.

  6. 06

    Retry flows

    Failure never dead-ends: retry, change method, or continue later.

04UX Decisions

01Validate before money talk

The UPI ID is checked the moment it is entered, so users never start a payment against an ID that cannot receive it.

02The review card

Payee, amount and reference are confirmed together on one screen. Nothing about money is decided in two taps.

03Pending is a first-class state

UPI confirmations lag. Instead of a silent spinner, the pending screen carries a timer and reassurance about what is happening.

04Never guess on failure

If the provider does not respond, the flow polls before reporting failure — a timeout is not assumed to be a failure.

05Every failure ends in recovery

Retry is the default action, changing method is one step away, and every screen answers the real question: where is my money?

05Interaction Design

States, transitions and behaviour — not just the happy path.

Invalid UPI ID

Inline, immediate, and actionable — with the field refocused for correction.

Unregistered UPI ID

A distinct state from invalid: the ID exists but cannot receive payments.

Transaction pending

Timer-based pending state with periodic status checks, never a frozen spinner.

Success

Reference number, amount, payee and next steps — a receipt people can read aloud.

Failure

Reason in plain language, money state stated explicitly, retry or alternate path offered.

Double-charge prevention

If a retry happens after an uncertain outcome, the UI states clearly that the previous attempt may still complete.

06Edge Cases

Good UX is what happens when things go wrong. Each case: the problem, the user-facing message and the recovery action.

UPI ID doesn't exist

Edge case

The entered ID is not registered anywhere.

“We couldn't find that UPI ID.”

Recovery: Correct and retry — before any amount is shown.

Connectivity failure

Edge case

The network drops mid-payment.

“We're having connection trouble. Your payment hasn't gone through.”

Recovery: Reconnect and check status — never assume a failure debited money.

Payment failed after debit

Edge case

The provider reports failure after the money was debited.

“Your bank debited the amount, but we didn't get a confirmation.”

Recovery: Auto-refund path with reference number and support contact — the worst state handled first-class.

Session expired

Edge case

The payment screen is stale.

“This payment session expired. Nothing was charged.”

Recovery: Restart from amount review, not from the beginning of the journey.

Retry limit

Edge case

Repeated failures on the same ID.

“This ID keeps failing. Want to try another way?”

Recovery: Switch to a different payment method or hand off with context.

07Final Experience

Primary action

UPI ID entry + validation

UPI ID entry + validation

One focused field, inline validation before any amount is shown.

Schematic placeholder — add an approved screenshot via data/case-studies.ts

Primary action

Review card

Review card

Payee, amount and reference confirmed on one screen.

Schematic placeholder — add an approved screenshot via data/case-studies.ts

Primary action

Pending state

Pending state

A timer, not a silent spinner — the user always knows the payment is being confirmed.

Schematic placeholder — add an approved screenshot via data/case-studies.ts

Primary action

Success receipt

Success receipt

Reference number in monospace, copyable, with next steps.

Schematic placeholder — add an approved screenshot via data/case-studies.ts

08Learnings

  • Money UX is state design: every screen answers 'what happened to my money?' in the first line.
  • Pending is where users panic. Design it like a product, not a spinner.
  • The double-charge fear is real — the interface must never create ambiguity about whether a retry is safe.

Next case study

Omni-Channel Contact Center Dashboard

All workNext case study

← /work · case study · upi-payment