Case Study

Over-the-counter payment processing

tl;dr

Designing an over-the-counter payment system aimed at enabling small to mid-size businesses accept in-person payments electronically.

Defining a point-of-sale product for a new market opportunity

Paymentus had built its business around digital bill payment. As the company explored opportunities beyond its existing market, Product identified in-person payment processing as a potential area for expansion.

I partnered with Product to define the requirements, interaction model, and user experience for a point-of-sale solution that would enable businesses to accept electronic payments over the counter. Rather than extending an existing product, we were defining a new product capability from first principles.

Defining the product before designing the interface

Unlike redesign projects, this work began without an existing product to improve. Together with Product, I helped define the workflows, concepts, and operational scenarios that would shape the experience before interface design began.

Our starting point was intentionally simple:

How should accepting an in-person payment actually work?

From there, we modeled the entire transaction lifecycle, identifying the tasks, decisions, and system behaviors required to support real-world payment scenarios.

Epics and user stories defined the initial scope of the point-of-sale platform, covering in-person checkout, invoicing, customer management, payment flexibility, and transaction history.

Modeling the payment journey before designing screens

Rather than beginning with interface layouts, I first mapped the end-to-end payment flow.

This exercise established a shared understanding of how cashiers, customers, and the payment system interacted throughout a transaction while exposing opportunities to simplify the experience before visual design began.

Every subsequent screen was derived from this operational model rather than being designed independently.

Over-the-counter payment flow. High-level journey from initiating a sale through payment selection, payment processing, and receipt delivery.

Letting the system do the work

One of the earliest product discussions centered around split payments. The initial proposal introduced a dedicated Split Payment feature that users would invoke whenever customers wanted to combine multiple payment methods.

I proposed a different interaction model.

Rather than asking users to explicitly choose a “split payment” workflow, the system could simply recognize when a payment didn’t satisfy the remaining balance and naturally continue accepting additional payment methods until the transaction was complete.

Partial payment decision flow. If the balance is not paid in full, the system automatically transitions into a split-payment workflow without requiring the cashier to manually select a separate mode.

This shifted complexity away from the user and into the system. The interaction became simpler because users no longer needed to decide which payment flow they were in.

Designing around outcomes instead of screens

Instead of designing the interface from the first screen forward, I worked backwards from the transaction outcome.

Beginning with the receipt and confirmation experience helped establish the information users ultimately needed to accomplish their task. From there, I designed each preceding interaction—payment review, payment method selection, and transaction initiation—to progressively support that outcome.

Working backwards ensured every screen existed to move users toward a clearly defined objective rather than simply continuing the workflow.

Payment method selection. Cashiers can complete transactions using card, cash, or gift card, with available options determined by store configuration.

Cash payment workflow. Frequently used tender amounts are presented as quick-select options, with the flexibility to enter custom amounts when needed.

Card payment standby state. The register waits for customer interaction on the payment terminal while providing a manual card entry fallback if the terminal is unavailable.

Transaction completion. A confirmation screen summarizes payment, change due, and provides immediate options to print or digitally deliver the receipt before starting a new sale.

Receipt delivery. Customers can receive receipts via email or SMS directly from the checkout flow, reducing reliance on printed receipts.

Separating products before separating interfaces

As requirements evolved, I noticed that the proposed product was attempting to satisfy two fundamentally different business models simultaneously.

Some requirements reflected the needs of businesses accepting payments in person. Others were specific to organizations issuing invoices and collecting payment remotely.

Treating these as a single workflow introduced unnecessary complexity because each use case optimized for different user goals. Rather than continuing to expand one increasingly complicated product, I proposed separating the problem into two distinct experiences.

One optimized for over-the-counter transactions.
One optimized for invoicing.

This decision reduced product complexity while allowing each workflow to evolve around its own operational needs.

A dedicated invoicing interface designed separately from counter checkout, enabling itemized billing and customer-based sales outside the in-person payment flow.

Cashiers can build invoices by searching products, adding line items, assigning customers, and reviewing totals before sending.

Existing customers can be searched and assigned to an invoice, or new customer records can be created without leaving the workflow.

Session timeout safeguard. An inactivity countdown protects sensitive customer and payment information while allowing users to extend their active session.

Delivering a product definition ready for implementation

As organizational priorities shifted, development of the product was postponed before implementation began. Although the experience was never built, the project successfully established the interaction model, product requirements, workflows, and supporting design deliverables necessary to support future development.

My contribution focused on defining how in-person payment processing should function as a product rather than simply designing how it should look.

Next Case