Google Pay — QR Checkout Redesign

At a glance

Problem

GPay may already know a bank is slow — but the user discovers this only after entering their PIN and getting stuck in a processing loop.

My Role

Analyzed the QR payment journey, identified behavioral friction patterns, prioritized the core problem, and wrote the PRD for two trust-sensitive interventions.

What I Designed

Two intelligent interventions: a pre-scan health banner and a smart auto-switch recommendation at account selection.

Why It Matters

In money movement, intelligence is only valuable if users understand and trust it. This project shows how to design AI nudges that are helpful without feeling intrusive.

Context

The high-stakes moment at the checkout counter

Google Pay handles the core payment job well. The opportunity here was not to reinvent payments — it was to improve one of the most stressful moments in the flow: paying at a busy physical counter.

In that moment, speed matters, social pressure matters, and trust matters. A few seconds of delay can feel much longer when there are people waiting behind you. When an app fails or hangs, most users don't calmly retry — they switch apps, switch to cash, or quietly stop trusting that payment flow.

The product was not broken. It was missing one thing: it gave users no warning before the failure happened.

Discovery

What the payment flow was actually hiding

The standard QR checkout flow looks straightforward. The problem wasn't the steps — it was what the app hid during them.

App Open

Scan QR

Enter Amount

Select Bank

Enter PIN

Processing…

Success / Failure

⚠️

Technical Uncertainty

The product already knows a bank is slow or degraded. The user doesn't — until it's too late.

⏳

Spinning Circle Anxiety

The 3-second delay after PIN entry creates genuine uncertainty. At a busy counter, that silence feels like failure.

🧭

Contextual Blindness

Users with multiple linked banks get no guidance on which account is most likely to work right now.

User Segments

Who feels this problem most

Not all GPay users experience checkout anxiety the same way. Three behavioral segments were identified — two were prioritized for the PRD.

Primary

Frictionless Transactor

A frequent QR payer who values speed and reliability above everything else. Any unexpected delay — even three seconds — breaks their mental model of how payments should work.

Primary

Budget Orchestrator

A multi-account user who wants contextual intelligence at account selection. Currently forced to manually guess which bank to use — with no health signal to guide the choice.

Secondary

Trust Seeker / Digital Skeptic

A more anxiety-prone user who needs explicit reassurance and recovery options. A failed payment without explanation can push them toward cash entirely.

Validated P0 Problem

Narrowing to one precise problem statement

After mapping the flow, the segments, and the friction signals, the evidence pointed to a single root cause. Everything else was a downstream effect.

P0 — Validated Problem Statement

Users face checkout anxiety and technical declines during QR payments because Google Pay fails to communicate real-time bank server health before the transaction starts.

Product Framing

Why this is a decisioning problem, not a design polish problem

The instinct with payment failures is often to improve the error screen. But that only addresses what happens after the user is already stuck. The stronger intervention is earlier.

GPay has access to signals that users don't have:

What GPay already knows

Bank latency in real time · Transaction failure rate trends · Which linked accounts are currently healthy · Likely success probability per bank

What the user sees

A default bank pre-selected · A PIN prompt with no context · A spinning indicator · A failure message — with no explanation of why

This is an information asymmetry problem. The product holds signals that could reduce anxiety, prevent failure, and guide better routing — but doesn't surface them at the moment they matter.

That's what makes it a strong intelligent decisioning use case. Not generative AI, not a chatbot. Just better guidance, surfaced at the right moment, from signals the product already has.

Ideation + Prioritization

From five ideas to two focused bets

Multiple solution directions were explored before applying RICE to narrow the field. The goal was to find the highest-impact changes that didn't require rebuilding the payment stack.

Idea	Reach	Impact	Confidence	Effort
Pre-Scan Health Banner Selected	High	High	High	Medium
Smart Auto-Switch Selected	Medium	High	Medium	Medium
Latency Warning at PIN	Medium	Medium	Low	Medium
Full Bank Health Dashboard	Low	Medium	Low	High

Key PM Decision

A full bank health dashboard was considered but rejected. It addresses a system-monitoring need, not the user's in-checkout anxiety. The two selected interventions work at the exact moment of highest friction — and require no extra navigation from the user.

Feature Deep Dive · 01

Pre-Scan Health Banner

Feature 01 of 02

Surface bank health before the user commits

User Context

A user opens GPay before scanning at a tea stall or busy merchant. They're about to commit to a payment without knowing whether their default bank is responsive right now.

How It Works

Before the user begins the transaction, GPay checks the current responsiveness of the default bank. If it's slower than usual, a subtle inline banner appears — "HDFC server: slower than usual" — before the scan.

Why It Matters

This removes the blind spot before the transaction starts. The user can switch banks or choose a different payment moment — instead of discovering the issue after entering their PIN.

Trust & UX Consideration

The banner must be informative, not alarming. A poor implementation triggers panic and pushes users away from GPay entirely. The tone matters as much as the signal.

⚠ Risk to design around

If the health signal is wrong — bank API shows healthy, but the transaction still fails — the banner loses credibility. The signal must be based on actual transaction failure spikes, not just delayed API response time.

Feature Deep Dive · 02

Smart Auto-Switch

Feature 02 of 02

Pre-select a healthier bank — visibly, not silently

User Context

A user has scanned a QR code and entered the payment amount. Their default bank is currently degraded. The account selection screen appears — with no signal that the default is a risky choice.

How It Works

Instead of defaulting to the unhealthy bank, the system pre-selects a healthier linked account and surfaces a visible, dismissible explanation of why. The user sees what changed and can undo it in one tap.

Why It Matters

Removes the manual switching friction for multi-bank users and prevents an avoidable failure. The Budget Orchestrator segment benefits directly — they want the system to use its context, not hide it.

Trust & UX Consideration

The system must never switch silently. A hidden account change in a payments product is a trust breach — users may not notice, pay from the wrong account, and lose faith in the product entirely.

⚠ Risk to design around

If the auto-switch isn't noticed or the messaging is unclear, users may accidentally pay from an unintended account. The intervention needs high-visibility messaging, not a subtle footnote.

Interactive Prototype

See the concept in action

A clickable prototype walking through the checkout moment — surfacing bank health signals, guiding account selection, and showing how the system communicates an intervention.

GPay QR — Concept Prototype

Open in New Tab

What this prototype demonstrates

Bank health visibility before failure

Recommendation clarity at account selection

User control during auto-switch

Trust-sensitive microcopy

Interaction flow during checkout anxiety

Nudge Design

How should the intervention feel?

Deciding what to build was the easier part. The harder design challenge was deciding how the system's interventions should land for a user already under social pressure at a payment counter.

Every design decision sat inside a tension:

Tension 01

Helpful

Alarming

Tension 02

Smart routing

User control

Tension 03

Intelligent nudge

Feels creepy

Tension 04

Confident guidance

Over-automation

In money movement, trust comes from clarity. A smart intervention is only valuable if the user understands it — otherwise it's just surprise.

The design principle that resolved most of these tensions: show the reason, always. If the system changes a user's path, the user sees why, immediately, in plain language. The undo option is always one tap away.

Success Metrics

How I'd evaluate this — proposed, not live

The goal of measurement isn't only counting successful payments. It's also verifying that warnings and nudges don't create new anxiety or suppress payment attempts.

Effective Transaction Success Rate

Did the rate of completed payments improve — particularly for users whose default bank was flagged as slow?

Primary signal

Auto-Switch Acceptance Rate

When a healthier bank is pre-selected, do users keep it or override? High acceptance suggests trust in the recommendation.

Trust signal

PIN Abandonment Rate

Did the banner cause users to abandon checkout entirely — or did it reduce PIN-stage drop-off by setting better expectations?

Watch carefully

Overall QR Scan Volume

A downstream indicator. If users trust GPay more at checkout, total scan volume should hold or grow after the intervention.

Long-term signal

Risks + Mitigations

The things most likely to go wrong

Risk

Health signal says the bank is fine — but the transaction still fails. The banner loses credibility, and users stop trusting it.

Mitigation

Base signals on actual transaction failure spikes — not just delayed bank API responses. Accuracy of the signal is a prerequisite for trust in the feature.

Risk

User misses the auto-switch notification and pays from the wrong account — causing a trust breakdown and a complaint to support.

Mitigation

High-visibility messaging, not a subtle indicator. One-tap undo. The account name and logo must be unmistakably visible in the confirmation screen.

Risk

The health warning causes users to exit GPay and switch to a competitor — net negative even if the bank was genuinely slow.

Mitigation

Frame every warning around a better alternative — not just a problem. "Your HDFC is slow — switch to SBI?" performs better than "HDFC may fail."

What I Learned

Three things this project sharpened

Intelligence is most useful before failure, not after. Explaining a failed payment is easy. Using the signals you already have to prevent it — and reducing anxiety in the process — is the harder and more valuable product move.

A good nudge is as much about explanation as prediction. If the system changes a user's path without making the reason clear, trust drops quickly. Clarity isn't a nice-to-have in fintech — it's a functional requirement.

Narrowing scope is where PM quality shows. Instead of redesigning the entire checkout, the work focused on one blind spot: hidden bank-health risk before the PIN step. That constraint made the solution sharper, not smaller.

Portfolio Context

Why this case study is in my portfolio

I'm including this project because it reflects how I think about AI product work in a trust-sensitive domain. The problem is practical — not hypothetical. The solutions required real prioritization decisions, not just good taste.

The work combines discovery, user segmentation, PRD writing, nudge design, metrics thinking, and risk analysis — all around a concrete user problem that millions of people face every day at checkout counters.

It is concept work, not shipped production. But it represents the kind of AI PM thinking I want to bring into real products — where intelligence earns trust by being useful, not by being visible.

Next step

Seen enough to want a conversation?

I'm open to AI PM roles where the problem is real. This is the kind of structured product thinking I bring to every challenge.

Open Live Prototype View PRD Artifact ← All Case Studies Let's Talk