Case study1 of 3

Amazon Pay

A clear view of a shop's money, from counter to bank.

I designed Amazon Pay's dashboard and phone app for merchants accepting scan-and-pay. Cashiers needed to confirm each shopper's payment; owners needed to reconcile it with the bank.

Customer: Merchants accepting Amazon Pay
My role: Lead Product Designer
Scope: Research → desktop → mobile
Delivered: Dashboard + phone app shipped
Year: 2019

Amazon Pay desktop dashboard showing amount received, amount settled to bank, stores and transaction history — One product, two places of work. The owner's overview and the cashier's live feed.Try the prototype

Phone dashboard showing today's receipts and recent payments — One product, two places of work. The owner's overview and the cashier's live feed.Try the prototype

The shopper could pay.
The shop couldn't see its money.

The merchant is Amazon Pay's customer here. The shopper is the merchant's customer. This product served the business receiving the money: its owner, managers and cashiers.

Amazon Pay was preparing to launch scan-and-pay. Merchants still pieced together payments from SMS threads and notebooks, then checked bank entries by hand. The consumer launch depended on giving them a working view.

As the sole designer on the merchant side, I spent two weeks visiting eleven merchants, then worked with PMs and engineers on the dashboard, refund rules and permissions. The desktop was the launch priority. The counters I visited made the case for a phone app next.

The same payment means different work.

At a cafeteria, the cashier sometimes relied on the buzz of a confirmation message because the app loaded slowly. A tea-stall owner wanted one daily view across his four branches. Those visits shaped two distinct jobs.

At the counter · seconds

Shwetha, the cashier

Has this shopper paid?

A queue is waiting. She needs a quick confirmation, a list she can trust, and a way to put a wrong sale right.

Design for a glance, a sound and a short action.

At the desk · close of day / next morning

Prakash, the owner

What did we take, and did it reach the bank?

He oversees several stores and decides who sees what: managers see the stores assigned to them, cashiers get confirmations for theirs. He needs the day's totals together and a settlement record he can match to his bank statement.

Design for comparison, a date and a traceable record.

Composite personas based on the visits; names are stand-ins.

Three decisions carried the product.

I used component libraries already cleared by InfoSec. The design work went into what happened when money arrived, moved or had to go back.

01 Confirmation · Shwetha, in seconds

Keep totals live.
Let bursts wait.

A constantly reordering list could move a payment under the cashier's hand. A single arrival gets a highlight and a ding. A burst waits behind See N new transactions until she brings it in. The total updates either way.

It costs her one more tap in a rush, at a moment she chooses.

A plain ding survived overlapping payments. Spoken amounts through Alexa stayed out: there was no budget for hardware at every till.

Desktop · recording

Fig. 1Single arrivals surface; bursts wait. Recording from the rebuilt prototype.

02 Refunds · Shwetha, in seconds

Let the counter
put a sale right.

Refunds were often partial: ₹40 back when a shopper paid ₹100 for a ₹60 bill. The cashier can start from the original payment and issue several partial refunds, each recorded against that sale.

The safer-looking option was a manager's approval on every refund, which would have held the queue for someone rarely at the counter. With typical tickets under ₹500 and the planned fraud controls, the PMs and I kept approval out. The confirmation says Refund initiated; completion still depends on the bank.

That leaves no second pair of eyes on a refund, and large-value and fraud cases waiting for a later design.

A ₹42 payment with separate partial refunds of ₹20 and ₹22, each carrying its own status — Fig. 2The refund stays attached to the sale, including multiple partial refunds.

What the phone carries

The visits also settled what the phone app would hold. Most counters had no laptop, so the phone carries the live feed, the ding and refunds; settlement reports, stores and users stay on the desktop, and the phone's menu marks them desktop only. Making the whole dashboard responsive would have put settlement tables on a screen nobody at a counter asked for.

An owner can't check a settlement from the shop floor.

The phone app's menu: Dashboard, Transaction History, Settings and Help, with Settlement Reports, Manage Stores and Manage Users listed under Desktop only — Fig. 3The phone's menu keeps the desk's work visible and marks it desktop only.

03 Reconciliation · Prakash, the next morning

Received isn't
the same as settled.

The printing-press merchant wanted to stop checking bank entries by hand. An amount received at the counter couldn't establish whether that money had arrived in the account.

A single balance would have been simpler to build, and it would have hidden exactly that gap. I separated received and settled amounts on the dashboard, with the settlement date visible, so the screen reports what the bank has done and never implies a payment is already in the account. The report groups a day's payments, deducts refunds, and shows the bank account and UTR reference for matching the deposit.

Prakash has a second number to learn on the first screen, and his morning question gets its answer there.

Separate dashboard tile showing the last amount settled to bank, its date and a link to the settlement report — Fig. 4A dated settlement on the overview; its full trail in the report.

Settlement report showing daily batches, refunds, UTR references, the destination bank account and underlying payments — Fig. 4A dated settlement on the overview; its full trail in the report.

The dashboard made launch.
The phone app followed.

Merchants gained a live view of receipts, refunds at the counter and a record of settlement at the desk.

What I can claim

Both products reached production. I didn't receive post-launch usage figures, so I can't quantify adoption or time saved. Issue reports were the only feedback that came back to me.

What I'd carry forward

Bank-side refund failure and recovery states never got built. I'd design that interval between initiation and bank completion explicitly, and keep a written record of those trade-offs with stakeholders from the first week.