Taking payment with the bill out of sight

One screen, very different shops

The platform is sold to shops that have almost nothing in common. Some take cash and nothing else. Some run six payment methods, sell on several ecommerce platforms at once, and carry their own loyalty scheme on top of three kinds of discount.

All of them use the same checkout screen.

What I built first

Each payment method opened a full-screen page: enter the amount, enter whatever else that method needs, come back. Only when every method had been entered did you complete the order.

The reasoning was not arbitrary. Done that way, the payment method is called once — which means the cart summary is recalculated once. Shipping, tax, discount, loyalty: until that moment they are parameters, not submissions. One call, one calculation, fewer ways to be wrong.

I still think that part was right. It is the rest that I had wrong.

The old checkout: payment methods and totals, with no sight of what was being bought. — The first version. Everything about the payment is here, and nothing about the order. Screens redrawn; the shop and the figures are fictional.

The same screen after a cash amount is entered. A surcharge has appeared; the order itself is still nowhere on screen. — The first version. Everything about the payment is here, and nothing about the order. Screens redrawn; the shop and the figures are fictional.

What the shops actually objected to

I expected the complaint to be about taps. It was not. What came back was that the full-screen page had taken the cart away.

A cashier typing 500 into a cash field is not entering a number. They are checking one number against another — the total, what has been paid, what is still owed, what has to be handed back. The screen I had built asked them to do that from memory, at the till, with a customer waiting.

The arithmetic was safe. The person doing it was not.

Two changes

The full-screen page became a modal. The payment method is still called once and the calculation still happens once — nothing about the data changed. What changed is that the screen underneath does not go away.

And the order summary moved into permanent view beside it, with every figure named rather than implied: what came in as cash, what came in through the gateway, what is still short, what goes back as change. Whatever the cashier is checking against, it is on screen now and it stays there.

Two changes, and neither of them cost me the thing the first version had been built to protect.

Entering cash in a modal. The order stays visible behind it, and the amount still owed updates as the cashier types. — The second version. The modal does not erase the order, and every figure the cashier is checking against is named rather than implied.

Two payment methods on one order, with cash received, card received and change due each named on screen. — The second version. The modal does not erase the order, and every figure the cashier is checking against is named rather than implied.

Looking back

I had treated entering a payment as a step. For the cashier it is not a step, it is part of checking. A step can take the whole screen. Checking cannot.

The first design was correct about the data and wrong about the room. Those are not the same kind of correct, and I could not tell them apart until somebody who stands at a till all day told me.

It shipped. I have no figures for it.

← All work