Fixing the POS Sale Model, 40% Fewer Merchant Issues

Overview

I was a product designer running a café as a side project. Using the POS terminal daily, I noticed something that took a few weeks to fully understand: the app had no concept of a sale. I documented the evidence, reached out to the provider, and signed a part-time contract to fix it.

Problem

In Iran, customers regularly pay with more than one card when their balance is insufficient, and groups of friends splitting a bill is completely normal. The app handled neither. Every card charge was a standalone transaction with no connection to others. Merchants restarted the flow from scratch for each card, tracked running totals in their heads, and kept handwritten notepads next to the terminal to fill the gaps the system left behind.

This wasn't a missing feature. It was a wrong assumption baked into the foundation of the app, and everything built on top of it was inheriting the problem.

Research

Over four weeks I spoke with 8 small business owners using the same app: three cafés, a clothing retailer, a bookstore, a supermarket, and two restaurants. I asked each to walk me through any transaction that didn't go smoothly.

Every single one described split-payment situations as a daily occurrence. More valuable was what each had built around it.

Two café owners kept handwritten notepads to log partial payments throughout the day. The notepad was the only place a split sale existed as a single entry.

The supermarket owner spent 20 to 30 minutes every evening reconciling her terminal report against her actual customer count. Her report showed 52 transactions. She had served 41 customers. The gap was invisible in the system.

One restaurant owner described a table of five friends paying separately. He processed five disconnected transactions with no shared reference, tracking the running total himself. If he made an arithmetic error, he had no way to audit it afterward.

Three owners mentioned their accountant had flagged persistent discrepancies between the terminal report and actual daily revenue that neither of them could explain.

Discovery

The app was built on one wrong assumption: one card charge equals one complete sale. In most payment contexts that holds. In small business reality, it fails multiple times a day.

Without a sale layer, four things broke consistently.

Transaction reports counted card charges, not customers. A merchant who served 38 customers but processed 47 charges had a report that was technically accurate and practically useless.

There was no recovery path when a card declined mid-payment. If a first card succeeded and a second declined, the merchant was stranded with no concept of an open sale to continue from.

Group payments had no container. Four friends paying separately generated four disconnected records with nothing linking them to a shared bill.

Receipts were per charge, not per sale. A customer paying with two cards received two receipts for one purchase.

The design problem was clear: the app needed a sale layer above the individual card charge, a container that grouped multiple payments, tracked completion against a total, and produced records that matched how merchants actually experienced their business.

Working with Stakeholders

A friend who worked as an engineer at the company connected me with the product team. I came with the full audit: merchant interview findings, a model diagram showing current versus merchant reality, and a mapping of every downstream consequence.

Their first response was that introducing a sale object above the transaction layer touched the data model, reporting system, and receipt generation. A significant architectural change.

My response was that every merchant I spoke with had already built their own manual solution to this problem. The product team had offloaded the complexity of their data model onto the people using it daily, and those people were absorbing it silently.

We agreed on a phased approach. Phase one, which became the contract, focused on the in-app split payment experience and sale grouping in transaction history. Full accounting and reporting integration was deferred and explicitly documented as a handoff for the next phase. I worked directly with the engineering lead (Android Developer) and project manager through two review cycles before release.

Design Process

Before any design work, I aligned with engineering on the new conceptual model. A sale is the unit of commerce: one customer interaction, one total amount. A payment is an event within a sale: one card charge. A sale holds one or more payments and has its own completion status independent of any individual charge.

Three decisions followed from that model.

Opening a sale before charging a card. The flow started by setting a total amount. The app then tracked what had been collected and what remained throughout the interaction, not the merchant.

Remaining balance as persistent state. After each charge the app showed the remaining balance and offered a clear next step: collect the remainder, or close as partially paid. If a second card declined the sale stayed open, the first payment was preserved, and the merchant had a path forward.

Sale-level records and receipts. The transaction history showed sales, not charges. Each entry showed total, completion status, and could be expanded to show individual payments. A customer paying with two cards received one receipt. A group of four received one receipt each showing their share and the full total.

Impact

The redesigned flows shipped as an app update across all platform users.

The restaurant owner who had been spending 20 to 30 minutes every evening reconciling reported that her transaction count matched her customer count from day one. Across the 8 merchants interviewed, end-of-day reconciliation time for split payment situations dropped from an average of 22 minutes to under 5 minutes.

At my own café, staff stopped using the handwritten notepad within the first week.

Within the first month post-launch, the provider's support team reported a 40% drop in contacts related to split payment confusion and reconciliation discrepancies.

Key Insights

The real problem was a model problem, not a workflow problem. Every symptom was downstream of one wrong assumption. Fixing the screens without fixing the model would have produced cleaner UI on top of the same broken records.

Merchant workarounds are a design brief. The handwritten notepad next to the terminal said everything: the app produces a transaction record, and I need a sale record. A designer's job is to see that gap before the merchant has to solve it themselves.

The split bill and the insufficient balance cases are the same design problem. Whether a customer can't cover the full amount on one card, or four friends want to pay separately, the solution is identical: a total, multiple payments collected against it, one coherent record at the end.

Scoping around architectural dependencies is a design skill. Deferring the reporting layer with clean handoff documentation was the negotiation that made the project shippable.