Amazon Pay — Merchant Dashboard

A merchant accepting Amazon Pay at a counter has one question all day long: did the money come in? And one question at close: what do I settle, and what's already in my bank? The Merchant Dashboard answers both.

Overview

The Merchant Dashboard is a mobile app that gives shopkeepers, cashiers, and multi-outlet owners a live view of payments landing in their account, a searchable history they can filter and reconcile, a self-serve refund flow, and an end-of-day settlement report — all on the device that's already in their hand at the till.

The work covered the full surface: dashboard, transaction history, refunds, settlement reports, and store/cashier management — across default, empty, loading, and error states.

The problem

Merchants live with a specific kind of anxiety

The customer says "paid," shows a screen, and walks out — but the merchant has no immediate, trustworthy confirmation that the money actually reached their account. At the end of the day, reconciling a stack of transactions against what's been deposited to the bank is tedious and error-prone. And when a refund is needed, it often means a call to support rather than something the merchant can do themselves.

For owners running more than one outlet, the problem multiplies: they need to know which store took what, and the person at the counter — often a cashier, not the owner — needs to be kept in the loop without handing them the keys to everything.

Research (store visits and merchant interviews, conducted within the 4-week design sprint) identified four core jobs:

• Confidence — see payments arrive in real time, without refreshing or guessing.
• Reconciliation — review, filter, and search the day's transactions, and understand what's settled versus pending.
• Self-serve refunds — issue full or partial refunds safely, from the phone.
• Multi-store control — manage stores and the cashiers who get notified when a payment lands.

Who it's for

The primary device is a phone, because that's what's at the counter — so the whole product is designed mobile-first rather than as a shrunk-down web dashboard. The audience spans the owner (wants the day's total, settlement status, and store-level control) and the cashier (needs a payment confirmation and little else), which is why notifications and permissions are scoped per role and per store.

The solution

Dashboard — the glance

The home screen answers the day's first question immediately: a single large "Amount received" figure with the transaction count beneath it, scoped by a period selector (Today / Yesterday / Last 7 / Last 30 days). Below it sits a short feed of recent transactions and a clear path to the full history.

Two details carry most of the trust:

• A real-time nudge — when new payments arrive, the feed surfaces a "See 10 New Transactions" prompt rather than silently reshuffling the list or interrupting the merchant mid-task. The merchant pulls the update in when they're ready, which keeps a busy counter from feeling chaotic.
• A settled-to-bank confirmation — a calm, dismissible banner ("₹13,547.56 settled to bank · on 8th May, 8.30 am") that closes the loop between money received and money in the bank, which are two different moments merchants care about.

Transaction History — scan, then drill

The history is a clean, scannable list grouped by day (Today, Yesterday, dated separators). Each row shows only what's needed to recognize a payment at a glance: customer, time, transaction ID, and the amount in green.

Detail is handled through progressive disclosure — tapping a row expands it in place to reveal the merchant order ID, POS ID, transaction status, and settlement status, plus the refund action. Nothing leaves the list; the merchant keeps their place.

Reconciliation is supported by a slide-in filter panel (date range, transaction status, settlement status) and a dedicated search for transaction or order IDs. Both have honest empty states — "There are no transactions matching the specified filters" versus "You do not have any transactions yet" — so the merchant always knows whether they've filtered something out or simply have nothing yet.

Refunds — guided, with guardrails

Refunds are a high-stakes action, so the flow is deliberate without being slow:

1. From an expanded transaction, Refund opens an amount entry (pre-filled with the refundable amount, editable via keypad — supporting partial refunds).
2. A confirmation step restates the decision in plain language: "Are you sure you want to refund ₹42.00 to Aaryan Rao?" with a clear way back to change the amount.
3. A success state confirms against the specific transaction ID, and the refund appears as its own line item in the transaction's history.

The model handles the messy reality of multiple partial refunds against one payment — each refund is recorded separately with its own amount, timestamp, and status.

Settlement Reports — the close

Each day's successful collections are batched and reported net of refunds, with a clear settled-to-bank vs. pending distinction and a per-day breakdown the merchant can use to reconcile against their bank statement.

Manage Stores & Cashiers

Owners can manage each store's name, ID, and address, and assign up to three cashiers per store. The rule that anchors the design: every time a payment is made to the store, the cashier gets an SMS — so the counter staff get confirmation without needing app access, and the owner keeps control. The cap and the SMS behavior are surfaced as plain copy right where cashiers are added, so the constraint never comes as a surprise.

Design decisions

• Mobile-first, not desktop-shrunk. The counter is the context. Every layout, tap target, and flow assumes one-handed use on a phone, not a back-office screen.
• Built on the Amazon Pay system. The visual language is consistent and deliberate: a single accent — Amazon's orange — reserved for primary actions (Refund, Confirm, Okay) so the next step is never ambiguous; green for received amounts; teal for links and selected states.
• Trust through language and confirmation. Status is always spelled out in words a merchant uses — Settled to bank, Pending settlement, Partially Refunded — rather than icons alone. Irreversible or money-moving actions get a confirmation step and an explicit success state.
• Real-time without overwhelm. Live data is opt-in to view (the "See N new transactions" pull), so the list never moves under the merchant's thumb while they're reading it.
• States as first-class work. The design accounts for zero data, no-filter-match, refunded and partially-refunded transactions, and high-volume "too many updates" — the cases that decide whether software feels reliable in the real world.

Outcome

The design shipped 1.5 years after completion, implemented pixel-perfectly despite the 18-month regulatory and deployment cycle. The solution unlocked self-serve refunds for the merchant base, significantly reduced support volume for refund requests, and gave cashiers the simple notification they actually needed — a ding and a day's summary — without exposing them to the full operational dashboard.

Reflections

What I'd do differently: tag more stakeholders from the get-go instead of "revealing" the product to them. There would've been a written record of all trade-offs and decisions instead of reconsidering everything at time of reveal. Be more bold at the workplace instead of acting like a hired hand and minding my own business.

What cashiers actually care about matters as much as what owners need. They want a ding to understand payment was made, and a summary of the day's payments — especially settlements. That simplicity was the unlock; everything else was architecture to serve it.