My Work / Compliant Payout POS
Case Study

Designing a Compliant
Payout System
from Scratch

A gaming technology client needed a way to issue non-monetary rewards to players — legally, reliably, and with zero room for operator error. There was no off-the-shelf solution. I designed the entire system end to end.

Role UX Designer & Researcher
Domain Kiosk / POS · Fintech · Gaming
Platform 1024×768 Touchscreen Kiosk
Timeline Discovery → Shipped, 1 week UX · 2 weeks total
20+
Edge Cases Surfaced
4+
Reward Types Supported
$0→$1K
Transaction Range Designed

Overview

The Problem Nobody Had Solved Yet

Gaming terminals in certain states are legally required to pay out winnings in non-monetary form — no cash, no direct bank transfer. The client's existing solution was manual and error-prone: an employee would verbally tell a player their options, then manually load a gift card for whatever amount they said.

The client needed a purpose-built point-of-sale terminal that could handle prepaid card issuance, split payouts across multiple reward types, enforce compliance limits automatically, and give store employees a guided, foolproof workflow — all on a fixed hardware spec with no existing UX precedent to reference.

I was brought in as the sole UX designer. There were no wireframes, no prior research, and no template to follow. The brief was essentially: figure out what this needs to be and build it.

⚖️
Legal Compliance Driver
State gaming regulations prohibited direct cash payouts. Every payout had to be in the form of a prepaid card, lottery product, or other qualifying non-monetary item — and the system had to enforce this automatically.
🧩
No Existing Solution
Standalone card-loading terminals existed but didn't support split payments, variable reward types, or integration with gaming terminal data. A custom-designed system was the only viable path.

Constraints & Context

Designing Within Hard Limits

Before sketching a single screen, I needed to understand exactly what I was designing within. This was not a typical mobile or web project — it was a fixed-hardware kiosk with banking API dependencies, regulatory constraints, and operator users who would be using it in a fast-paced retail environment.

01
Fixed Hardware
1024×768px touchscreen, 8" diagonal, landscape orientation only. No responsiveness needed — but every tap target, every layout decision had to be optimized for this exact canvas.
02
Load Limits
Minimum $20, maximum $1,000 per card. Per-store velocity caps on 24-hour total load amounts and card count. System had to enforce these silently — no workarounds possible.
03
No Void Capability
Phase 1 had no transaction void or reversal. If an employee loaded a card for the wrong amount, there was no undo. The design had to make errors as unlikely as possible.
04
Online Only
All card activations required a live API call to the banking partner. No offline mode in Phase 1. Connectivity errors and bank denials had to be handled gracefully in the UI.
05
Flexible Reward Types
The "other items" category (lottery tickets, merchandise, etc.) was intentionally open-ended — store-specific and subject to change. The system had to accommodate reward types that didn't exist yet.
06
$2 Activation Fee
Each card carried a $2 fee deducted from the load amount. This had to be surfaced clearly at every step — before, during, and on the receipt — to build player trust and prevent disputes.

Discovery Process

20+ Questions That Shaped the Design

Before touching a wireframe, I ran a structured stakeholder Q&A with the client and their banking partner. Many of these questions surfaced critical design decisions — and several revealed gaps the client hadn't yet considered.

Can the cashier split a payout — apply part to a gift card and use the rest for other purchases like lottery tickets?
Yes. Players could allocate winnings across multiple reward types in a single transaction.
This single answer tripled the complexity of the flow. I had to design a split-payment module that tracked remaining balance in real time across variable reward combinations.
What if an employee loads a card for $400 but it was supposed to be $40?
No void available in Phase 1. System voids may be available as a future capability, but are not guaranteed.
Confirmation screens with explicit amount + fee breakdown became non-negotiable. I added a "Go Back" step before any API call so errors could be caught before they were irreversible.
If the barcode scanner fails, should employees be able to manually enter the card number?
Likely yes, but needs bank verification on acceptability before implementing.
I designed both paths — scanner primary, manual entry fallback — and flagged it as a dependency to resolve with the banking partner before launch.
What happens if a player loses their card?
Cards can be marked lost/stolen and replaced by mail. Players call a support line. The receipt — specifically the reference number on it — is the key to replacement.
This made the receipt a critical UX artifact, not just a confirmation. I ensured the reference number, support phone number, and card details were prominent on every receipt.
Are there daily or transactional limits per store?
Yes — per-store velocity caps on 24-hour total load amount and card count, managed server-side by the banking partner.
I designed error states for velocity cap hits that gave employees actionable next steps (contact support) rather than a generic failure message.
What is the maximum amount that can be loaded onto a single card?
$1,000 maximum, $20 minimum. Fee is included in the load amount and deducted by the backend processor on activation.
The UI had to enforce both bounds silently — disabling the Enter button below $20 or above $1,000 — and clearly communicate to employees why a transaction couldn't proceed.

Design Decisions

How I Solved the Hard Problems

Every major design decision was driven by a constraint, an edge case from discovery, or a user error scenario I needed to prevent. Here are the ones that mattered most.

1
Two Distinct Progress Indicators for Two Distinct Concepts
The flow has two things to track simultaneously: where the operator is in the workflow (steps), and how much of the payout has been allocated (money). Using the same visual treatment — a horizontal bar — for both would create ambiguity. I separated them intentionally: a step progress bar lives in the status area and tracks workflow position, while a balance tracker card communicates remaining dollar allocation. They never compete because they speak different languages.
Prevents Over-Allocation Reduces Disputes Added UI Complexity
2
Fee Transparency at the Point of Decision
Rather than deferring fee disclosure to a confirmation screen, I surfaced each card's net spendable balance ($148) at the exact moment the cashier chooses how many cards to issue. If a player asks "how much will be on my card?" the answer is visible before the decision is locked in. The fee appears once, clearly, at the right moment — not repeated on every screen in a way that creates anxiety rather than clarity.
Builds Trust Reduces Support Volume More Content Per Screen
3
Review Screen, Not a Confirm-Confirm
Because there was no void capability in Phase 1, I designed a Review screen that shows the full transaction breakdown before any API call. The critical distinction: this screen is named "Review Transaction" and the CTA is "Activate Cards" — not "Confirm" on a screen already called "Confirm." Asking the operator to confirm that they want to confirm is redundant friction. One clear review moment, one clear action label, with "Go Back & Edit" always reachable.
Catches Errors Before Lock-in Reduces Operator Risk Adds One Extra Step
4
Open-Ended "Other Items" Module
The client couldn't define all possible non-card reward types upfront — lottery tickets, merchandise, and other items would vary by location and change over time. I designed the Other Items module as a flexible, freeform entry system rather than a fixed dropdown, allowing store employees to add any item type with a description and amount without requiring a software update.
Future-Proof No Releases Needed for New Types Less Structured Data
5
Receipt as the Recovery Artifact
Discovery revealed that the receipt was the player's only recourse if a card was lost or damaged — it contained the reference number needed to initiate a replacement via mail. I treated the receipt as a first-class UX deliverable, ensuring prominent placement of the reference number, support phone number, and clear card balance information.
Enables Card Recovery Reduces Support Calls Printer Dependency
6
Auto-Print on Transaction Completion
Given the receipt's role as the player's only card recovery path, making print dependent on an employee action introduced an unnecessary failure point. A missed tap means a player walks away without their only safety net. I designed the system to trigger a print automatically on successful activation, with the completion screen confirming the print occurred and offering a reprint button as a secondary fallback for paper jams or player requests.
Eliminates Human Error Protects Every Player Faster Throughput Requires Reliable Printer

Key Screens

The Flow in Detail

Seven screens that represent the core decision points of the system — each designed to prevent a specific category of error while keeping the employee workflow fast and guided.

Click to expand PIN Authentication
1 — PIN Authentication
Filled dots provide real-time input feedback without revealing digits. Support number always visible — critical for an operator-only kiosk with no IT on site.
Click to expand Amount Entry
2 — Amount Entry
No balance tracker here — the player hasn't entered anything yet so "Remaining: $500" would just restate what they're about to type. Min/max shown in the input field hint. Continue key is same size as 0 and CLR — part of the numpad grid, not a separate button that breaks the rhythm.
Click to expand Split Payment
3 — Add Other Items
Continue to Cards is always enabled — remaining balance flows to cards by default. "Add Item" is a secondary action. Existing entries have a delete control. The balance tracker shows remaining allocation; the step progress bar (top) tracks workflow position using separate visual languages for two distinct concepts.
Click to expand Card Assignment
4 — Card Assignment
$500 total removed — this screen only covers the card portion, so showing a total without the lottery line would create misleading math. Per-card spendable ($148) is the only number that matters here. Step bar advances to 60%.
Click to expand Review & Activate
5 — Review & Activate
Screen is now called "Review Transaction" and the CTA is "Activate Cards" — the cashier is reviewing, not confirming twice. The warning banner names the action explicitly: "Tap Activate to issue cards." No redundant confirm step. "Go Back & Edit" always available.
Click to expand Card Scanning
6 — Card Scanning
Card count in status bar ("Card 1 of 2") maintains orientation. Manual entry fallback is always visible — not buried. Cancel is red to signal a destructive action.
Click to expand Completion & Auto-Print
7 — Completion + Auto-Print
Receipt auto-prints on completion — no cashier action needed. Total Payout is $500 gross (the full amount owed). Spendable balance per card ($148 after $2 fee) highlighted in green so the player knows exactly what they can spend. "Reprint" available as fallback; primary CTA is "New Transaction" to keep throughput high.

Outcomes & Reflection

What This Project Delivered

This was less of a typical UX project and more of a product definition exercise. The majority of the value I added was upstream — in the discovery process, the edge cases surfaced, and the architectural decisions made before a single screen was finalized.

✅
A Compliant System, End to End
Every payout flow was designed around the legal requirement for non-monetary payouts. The system enforces compliance at the UI level — employees cannot accidentally issue cash or bypass the card/reward structure.
🛡️
Error Prevention by Design
With no void capability in Phase 1, the design's confirmation architecture became the primary safeguard against operator error. Real-time balance tracking and explicit confirmation gates reduced the risk of irreversible mistakes.
🔭
Built for What Comes Next
The open-ended reward type module and flexible split-payment system were designed to accommodate reward types that didn't exist at launch. Phase 2 features (void, reporting, offline mode) were identified and scoped during discovery.
💡
Discovery as the Core Deliverable
The 20+ stakeholder questions I surfaced during discovery — particularly around error handling, lost cards, velocity limits, and receipt requirements — shaped the system's architecture more than any individual screen design.

"The most important UX work on this project happened before I opened Figma. Understanding what the system couldn't do — no voids, no offline, no reprints — shaped every screen I designed. Constraints aren't limitations. They're the brief."

— Stephanie Gross, UX Designer