Why We Obsess Over the Payment Flow — Every Tap Counts During Rush Hour

30 Seconds That Determine Everything

In a typical cafe transaction, the payment flow is the final moment — customer has chosen their order, cashier has entered it, just need to pay. Should be simple, right? But from our observations, this is exactly where the most friction occurs.

The cashier needs to select a payment method, enter the amount, calculate change (for cash), verify payment success (for digital), and only then move to the next customer. Every second lost in the payment flow is a second that can't be recovered — and with 50 transactions per shift, small inefficiencies in the payment flow compound into a major problem.

First Design Decision: Numpad, Not Keyboard

When designing the payment amount input, the easiest option for developers is using the standard system keyboard. But a standard keyboard on a tablet is a nightmare for cashiers: tiny keys, irrelevant letters, and positioned at the bottom of the screen forcing an awkward hand stretch.

We built a custom numpad — large numbers, natural thumb positioning, consistent layout. This sounds trivial, but the impact is significant: cashiers can input amounts without looking at the screen, because button positions become muscle memory.

There's a trade-off: a custom numpad means we build and maintain our own component. The system keyboard is "free." But this trade-off is worth it because the payment flow is used in every single transaction — improvements here have the largest multiplier effect.

Quick Amount Buttons: Eliminating the Need to Type

An interesting observation: in many cash transactions, customers pay with common denominations — a $10 bill, a $20, "exact change." If every time the cashier has to type this amount manually, that's repetitive work that should be eliminated.

We added quick amount buttons: shortcut buttons for the most commonly paid amounts. One tap, amount fills in, change calculates automatically. For a $4.50 order paid with a $10 bill, the cashier needs just one tap — no typing 1-0-0-0.

What's more interesting: these quick amount buttons can be intelligent — suggesting amounts based on the transaction total. If the total is $4.50, suggest $5 and $10. If it's $13.50, suggest $15 and $20. This reduces the cashier's cognitive load from "how much did they give me?" to "tap the matching button."

Split Payment: A Feature We Almost Didn't Build

"The customer wants to pay half cash, half QR." We initially thought this was an edge case — how often does it happen? Turns out: often enough to cause real confusion.

Without split payment, cashiers have to workaround: process one payment method, void the remainder, process the second method... messy. With proper split payment, it's: select method 1 → enter amount → select method 2 → enter remainder → done. Clean, recorded, reconcilable.

Our lesson: edge cases that involve money aren't edge cases. If handled incorrectly, the impact hits cash discrepancies and reconciliation directly. Better to support it properly from the start than force cashiers to improvise workarounds.

Automatic Change Calculation: Eliminating Mental Math

This is a philosophy we hold throughout the payment flow: if it can be calculated automatically, don't ask a human to calculate it. Not because cashiers can't do math — but because manual calculation under pressure (long queue, customer waiting) is a preventable error source.

Total $4.50, customer hands over $10 → change of $5.50 displays automatically. Cashier just retrieves the amount shown from the drawer. Zero mental math.

A positive side effect: new cashiers who aren't yet comfortable with fast transactions can still handle payments without errors, because the system does the calculation — not their memory.

Why We Chose "Select Payment Method First, Then Enter Amount"

There are two possible flows:

• Option A: Show all payment methods → cashier selects → then enters amount (for cash) or waits for confirmation (for QR).
• Option B: Cashier enters amount first → then selects payment method.

We chose Option A. The reason: the payment method determines what happens next. For cash, the cashier needs to enter the amount and see the change. For QR, the cashier needs to display a QR code and wait for confirmation. Two different flows — and selecting the method first ensures the cashier enters the right flow immediately without backtracking.

In Option B, the cashier enters the amount but doesn't yet know what flow comes next. This makes the experience less predictable.

Single Screen vs Multi-Step Wizard

Our longest internal debate: should the payment flow be one screen (all options visible at once) or multi-step (one action per screen)?

We settled on a hybrid: payment methods and numpad on one screen (minimize taps), but QR confirmation on a separate screen (because QR codes need to be large and clearly visible). This is a compromise between speed (one screen = less navigation) and clarity (QR needs dedicated space).

Metrics We Track

We don't just design the payment flow based on intuition — we measure:

• Tap count from "ready to pay" to "done." For cash payment with common denominations: 2 taps (select method + quick amount). That's our target to maintain.
• Average time from method selection to transaction complete. Target: under 10 seconds for cash, under 15 seconds for QR (including customer scan time).

The Bottom Line

The payment flow is "just" 30 seconds per transaction. But 30 seconds × 100 transactions per day × 30 days = 1,500 minutes per month = 25 hours. Improving the payment flow by 5 seconds per transaction saves 4 hours per month. For a cashier working 7-hour shifts, that's more than half a shift "returned." That's why we obsess over every tap — because at aggregate level, every second truly matters.