Designing Stored Value & Balance Passes

Daniel Baudino

Updated February 11, 2026

Overview

Stored value passes track units — sessions, visits, credits, punches, rides, meals.

The design challenge: make remaining value obvious and redemption unambiguous. If a user ever has to ask "how many do I have left?" — the design has failed.

What moment are you designing for

Someone arrives wanting to use what they have left.

Staff need to confirm: - How many units remain? - What are the redemption rules? - Did redemption succeed?

The user needs: - Certainty about remaining value - Confidence the transaction was recorded - No confusion about what the unit means

Stored value passes fail when units are unclear, remaining value is buried, or redemption doesn't visibly update the pass.

The unit confusion problem

A customer shows their pass: "I have 3 left."

Staff: "3 what? Sessions? Credits? Dollars?"

Customer: "I... don't know. It just says balance: 3."

The fix is simple but non-negotiable: - "Classes remaining: 3" — not "Balance: 3" - "Credits: 120" — not "Points: 120" - "Visits left: 2" — not "Value: 2"

Label the unit explicitly. Never assume users know what the number means.

Why must you choose the unit and never confuse it

Stored value often fails when units are unclear:

• Sessions vs. visits (are they the same?)
• Credits vs. dollars (can I spend credits like money?)
• Remaining vs. earned (did I earn 5 or do I have 5 left?)

Make the unit explicit and stable: - "Classes remaining: 3" - "Credits: 120" - "Visits left: 2" - "Punches: 7/10"

Never use ambiguous terms like "balance" for non-monetary units. "Balance: 3" could mean dollars, credits, visits, or something else entirely. Specific unit labels eliminate confusion.

Why is remaining value — not original — the hero element

Stored value passes often make the wrong value prominent:

• Original value — "10-class package" (nice to know, but not actionable)
• Earned value — "You've completed 7 classes!" (celebrates the past, not the present)
• Remaining value — "Classes remaining: 3" (answers the actual question)

Make remaining value the hero. This is what users check before deciding to use the pass. This is what staff need to confirm at check-in. Original value can appear as secondary context; earned value can appear as progress; but remaining value must be instantly visible.

Why are updates the entire product

A stored value pass that doesn't update is a liability. Users cannot trust the displayed value. Staff have to check manually. The pass becomes decoration rather than function.

Update on: - Redemption (unit consumed) - Refunds or adjustments (units restored) - Top-ups or purchases (units added) - Corrections (administrative fixes) - Expiration changes (validity period adjustments)

Updates should happen immediately after redemption. The user should see their new remaining value before leaving the service location.

When should stored value passes use validation

If value can be spent, validate. Stored value passes almost always need validation to:

• Prevent double-redemption
• Create audit trails
• Enable staff to confirm redemption
• Track usage patterns

Validation approach: - QR/barcode for universal compatibility - NFC where hardware supports it - Always include staff-readable identifier for scanner failures

Skip validation only when the pass is purely a reference object — rare for stored value scenarios where units are actually consumed.

How do you handle multiple unit types

Some passes track multiple things: money and points, classes and credits, visits and rewards. Multiple units create complexity.

If you must have multiple units: - Establish clear hierarchy (which is primary?) - Display primary unit most prominently - Separate secondary units visually - Never let secondary units compete with primary

Better approach: - One pass, one unit type - Use separate passes for separate value types - Link passes through account rather than cramming everything together

Multiple units with no hierarchy is the most common stored value design failure. Users cannot determine what they have or what they can redeem.

How do Apple and Google handle stored value passes

Both platforms support stored value through store card or generic pass types. Google Wallet's LoyaltyObject includes native progress indication that works well for punch-card style passes.

What are the most common stored value design mistakes

Showing original value as the hero — "10-class package" instead of "Classes remaining: 3." Users need remaining value.

Multiple balances with no hierarchy — Money + points + credits all equally prominent. Pick one primary unit.

Ambiguous unit labels — "Balance: 3" could mean anything. Be specific about the unit.

Burying redemption method — QR hidden behind taps or on the back. Validation should be immediately accessible.

QR as decoration — Barcode embedded in imagery breaks scanning. Always use native rendering.

No visible update after redemption — Users cannot confirm the transaction was recorded. Pass should change immediately.

Making stored value passes easy with PassNinja

PassNinja helps businesses create stored value passes with clear unit tracking and instant updates. Define your unit type, initial quantity, and redemption rules — PassNinja generates passes that track value accurately.

With PassNinja, redemption updates propagate immediately. Every class, visit, punch, or credit is recorded and reflected on the pass before the user leaves. Staff scan, confirm, and the value adjusts automatically.

The shift

Stop designing stored value passes as balance trackers. Start designing them as instant answers.

"How many do I have left?" The pass should answer before anyone asks. Clear unit. Current value. No confusion.

When a customer walks up, shows their pass, and the staff nods — no questions, no checking, no hesitation — that's the design that works.