Redesigning POS Payments Around the Sale

Overview

While running a café alongside my product design work, I used the same Android POS terminal as my staff. A customer could pay with several cards, but the app treated each charge as a separate transaction. There was no shared record of the sale or the amount still due.

I documented the problem, brought merchant research to the provider, and joined the project on a part-time contract. Working with the product manager and Android developer, I redesigned split payments, payment recovery, and transaction history around a sale that could contain multiple payments.

Walkthrough of the redesigned sale flow, with multiple payments linked to one purchase.

The problem: one sale, several disconnected payments

When a customer used a second card or a group split a bill, merchants restarted the payment flow for each charge. They calculated the remaining balance themselves and used handwritten notes to connect payments that belonged together. Receipts and transaction history reflected individual charges rather than the complete purchase.

Comparison of the app's card-charge model and the merchant's sale model.

Research with eight merchants

Over four weeks, I spoke with eight owners using the same app: three cafés, a clothing retailer, a bookstore, a supermarket, and two restaurants. I asked them to walk through payments that had been difficult to complete or reconcile.

Merchant interview findings about split payments and reconciliation.

All eight described split payments as a recurring part of their work, and six of them kept a manual notepad to track partial payments. A supermarket owner reported spending 20–30 minutes on evening reconciliation because her terminal counted charges while she was checking customer purchases. A restaurant owner described processing five separate payments for one table and keeping the running total himself.

These interviews helped identify the model mismatch and its consequences. The sample was small and focused on existing users of one POS app.

A sale needed its own record and status

The app needed to distinguish the total purchase from the events used to pay for it. A sale would hold the total amount, linked payments, remaining balance, and completion status. Each card charge would remain a separate payment within that sale.

A sale needed to hold the total, remaining balance, and status, while keeping each card payment as a separate event.

Gaps caused by recording card charges without a shared sale record.

This model addressed four connected problems: disconnected records for group payments, no clear recovery after a card declined, separate receipts for a single purchase, and transaction counts that were difficult to reconcile with sales.

Summary of the sale model and declined-card recovery described above. This diagram does not represent the payment processor’s implementation.

Agreeing the first release with product and engineering

I presented the interview findings, current flow, and model comparison to the product team. Engineering identified dependencies in the data model, reporting, and receipt generation. Together, we scoped the first release around split payments and sale grouping in the app's transaction history.

Full accounting and reporting integration remained outside this phase. I documented that dependency for the next phase and worked through two review cycles with the product manager and Android developer before release.

We scoped the first release around split payments and sale-level history, with accounting integration deferred to a later phase.

Designing the Android terminal flow

We aligned on the sale model before redesigning the screens. The previous flow showed where merchants had to restart a transaction and calculate the outstanding balance.

On the Android terminal, the merchant needed to read the payment state and decide what to do next while serving a customer. I organized the flow around the sale total, the amount collected, and the balance still due. These values connected amount entry, payment recovery, and history, so the merchant could continue the same purchase without reconstructing it from separate charges.

Previous POS payment flow with separate card transactions.

1. Set the sale total before collecting payments. The merchant entered the purchase amount once. Each successful charge reduced the balance on that sale, so subsequent payments continued against the same total.

2. Keep the remaining balance visible. After each payment, the app showed the amount collected and the amount still due. The merchant could continue collecting payments or leave the sale partially paid, with the outstanding balance visible. A partial payment was distinct from a fully paid sale.

3. Group records at the sale level. History showed a sale's total and completion status, with individual payments available inside the record. Receipts could reflect the full sale or an individual's share of a group payment.

Redesigned POS flow for collecting multiple payments against one sale.

Recovering from a declined card

If one card succeeded and the next declined, the sale remained open. The completed payment stayed attached to it, and the merchant could see the outstanding amount before choosing the next action. This made recovery part of the payment flow rather than requiring a new, disconnected transaction.

A declined card should leave the completed payment intact and the remaining balance visible.

Before and after comparison of recovery when a card payment fails.

This recovery flow concerns a confirmed card decline. A pending or unknown payment result is a different condition; the examples here do not demonstrate timeout handling, duplicate-charge prevention or settlement behavior.

Making transaction history match the purchase

A sale-level history entry connected the total, status, and individual payments. Merchants could inspect the payments behind a sale without reconstructing the relationship from separate entries.

Before and after comparison of sale grouping in POS transaction history.

Reported outcomes after release

The redesigned flows shipped in an app update. Merchant follow-up: The same eight merchants reported that average end-of-day reconciliation time for split-payment situations fell from 22 minutes to about four minutes. This measure concerned reconciling split payments, rather than the duration of the payment itself. At my café, staff stopped using the payment notepad during the first week.

Provider support report: The support team reported 40% fewer contacts related to split-payment confusion and reconciliation discrepancies in the first month after launch. This was a change in reported contact volume, rather than a measured error rate across all transactions. Both outcomes came from follow-up reporting, not a controlled comparison.

Reported changes in reconciliation time and payment-related support contacts.

What I learned

Merchant workarounds exposed a missing relationship in the product's model. The notepad linked payments to a purchase, so that relationship needed to exist in the app.

Split bills and payments across several cards could share one underlying model, while keeping the amounts and next actions clear for the merchant.

The release also depended on agreeing boundaries with engineering. Deferring accounting integration let us address the in-app payment experience while making the remaining dependency explicit.