Commerce Platform • Product Strategy • Payments Architecture • Workflow Design
Turning unmanaged overpayments into a controlled store credit system
As order volume grew, overpayments, partial refunds, and returns accumulated faster than support and finance could manually track — creating disputes, unrecognised liabilities, and avoidable revenue leakage.
- ✓Removed spreadsheet and note-based credit tracking
- ✓Established auditable control over customer liabilities
- ✓Reduced support handling time on credit disputes
- ✓Created a scalable foundation for refunds and loyalty
Commerce platform scaling order and payment volume
Overpayments and refunds tracked manually, with no reliable customer balance
Product strategy, workflow architecture, UX definition, delivery support
A controlled, auditable store credit system integrated into checkout and finance
Outcome first
Business Outcomes
The work was framed as a financial control problem, not a UI problem. The goal was to make customer credit visible, governed, and reconcilable at scale.
Made credit a governed liability
Credit moved from ad-hoc notes to a tracked balance on the customer account, visible to every team and reconcilable against the ledger.
Introduced issuance and approval controls
Rules defined who can issue, adjust, and expire credit — removing discretionary decisions from individual support agents.
Removed manual reapplication
Credit applies automatically at checkout and against open invoices, eliminating case-by-case handling and human error.
Established a scalable payments foundation
The same balance model now supports refunds, goodwill gestures, and future loyalty mechanics without new workarounds.
The business problem
The Challenge
Overpayments, partial refunds, and returned items generated money the business owed customers — but the platform had no structured place to hold it.
Balances lived in support notes and finance spreadsheets. Customers chased credit nobody could locate, agents improvised, and finance could not reconcile what was owed.
As volume grew, this stopped being an inconvenience and became a financial control and trust risk.
"Customers kept asking about credit nobody could find in the system."
Money owed to customers never appeared as a balance the business could report on.
Each agent applied credit differently, with no policy or approval path.
Finance could not trace credit back to the original payment or order.
Manual handling grew linearly with order volume and support headcount.
Framing
Discovery & Product Definition
Before designing any screen, we mapped the full credit lifecycle across three perspectives — the customer, the support agent, and finance — and identified where the current process silently lost money.
Store credit was never a checkout feature. It was an unrecorded liability being managed by people instead of the system.
Once credit was modelled as a first-class balance with its own lifecycle, the support, checkout, and reconciliation problems resolved as consequences rather than separate features.
Lifecycle Mapping
Every event from overpayment detection through issuance, partial use, and expiry was defined explicitly.
Policy Definition
Worked with finance to set rules for expiry, partial application, transferability, and refund-to-original-method.
Support Journeys
Captured the real cases agents handle today and the points where they are forced to improvise.
Accounting Alignment
Ensured every credit movement produces a reconcilable entry against the original transaction.
Product strategy
Key Product Decisions
A small number of structural decisions determined whether the system would stay controllable as volume increased.
Model credit as a balance, not a discount
Discount logic is transactional and disposable. A balance carries history, ownership, and a reconcilable value — which is what finance and auditors require.
- ✓Credit is reportable as a liability
- ✓Every movement traces to a source transaction
- ✓Supports partial use across multiple orders
Separate issuance from application
Issuing credit is a financial decision; applying it is an operational one. Splitting them allowed policy control without slowing down checkout.
- ✓Approval controls sit only where risk exists
- ✓Checkout stays frictionless for customers
- ✓Clear segregation of duties for audit
Automate detection of overpayments
Relying on agents to notice overpayments guaranteed inconsistency. Detection had to be a system responsibility triggered at payment settlement.
- ✓No overpayment goes unrecorded
- ✓Customers are notified without agent action
- ✓Support workload decouples from order volume
Make expiry explicit and visible
Silent expiry creates disputes and reputational damage. Making terms visible at issuance and in the account protects both the business and the customer relationship.
- ✓Predictable liability ageing for finance
- ✓Fewer disputes and escalations
- ✓Clear customer expectations at every step
System design
Defining the Solution
We modelled store credit as a first-class balance on the customer account, with defined rules for issuing, applying, reconciling, and expiring credit.
Detect Overpayment
Issue Credit
Notify Customer
Apply at Checkout
Reconcile
End-to-end lifecycle for store credit and overpayments, from detection through reconciliation.
Validating the workflow
Exploring the Experience
A structured competitor review tested how seven accounting platforms create, surface, apply, and reconcile customer credit. Comparing the same lifecycle across each product revealed which patterns were established, where terminology created confusion, and where the new experience needed a deliberate point of view.
The analysis translated fragmented market patterns into one coherent direction: detect overpayments, record customer credit, surface it on invoices, support controlled allocation, and reconcile the remaining balance.
In the product
Final Product Experience
The final experience embeds credit handling into the places where finance teams already work. The same controlled balance remains visible and actionable across the customer overview, payment registration, invoice allocation, and refund workflows.
A shared financial view of customer credit
The customer finance dashboard brings receivables, cash, overpayments, refunds, and store credit into one operational view. Finance teams can understand the total liability and trace every movement without switching tools.
- ✓Credit balance separated by source and consolidated into one total
- ✓Transaction history preserves the link between payments, invoices, refunds, and credit
- ✓Issue, apply, and refund actions are available from the customer context
Register credit at the point of payment
When money is received without immediate invoice allocation, the operator can explicitly register it as store credit. The workflow captures the payment account, date, amount, and credit type before posting.
- ✓Clear choice between customer credit and invoice payment
- ✓A dedicated credit type prevents ambiguous payment treatment
- ✓Projected balance makes the financial consequence visible before confirmation
Convert overpayments into controlled credit
Bulk payment registration allocates the received amount across outstanding invoices and automatically identifies any remainder. The surplus becomes a traceable store credit balance instead of an unresolved reconciliation item.
- ✓Invoice-level allocation preserves the source of the overpayment
- ✓The payment summary explains allocated value and remaining credit
- ✓The new customer balance is confirmed before the payment is registered
Apply credit without breaking the payment workflow
Available credit can be applied to an invoice alone or combined with a new payment. Allocation controls and a live summary show how each source changes the outstanding invoice and remaining customer balance.
- ✓Partial credit application supports real-world payment scenarios
- ✓Credit and cash remain distinct throughout allocation
- ✓The final summary keeps invoice and liability effects transparent
Refund from the correct credit source
The refund workflow lets finance select the originating balance and records how the refund changes the customer liability. Source-level allocation keeps the operation auditable from request through settlement.
- ✓Refunds can draw from available credit, overpayments, credit notes, or booked credit
- ✓Account and recipient details are captured before money leaves the business
- ✓The summary confirms both the refund source and resulting balance
Role & ownership
Our Contribution
End-to-end product leadership — from discovery and strategy through workflow definition and delivery support.
Business outcomes
What Changed
Customers, support, and finance now share a single, trustworthy view of credit — with no spreadsheets in the loop.
Lessons & principles
Strategic Takeaways
Financial features are control problems
When money is owed to a customer, the design question is governance and traceability long before it is interface.
Manual workarounds are a scaling signal
Processes handled by people are stable at low volume and fail predictably as volume grows — they are the clearest indicator of missing product structure.
Model the object, not the screen
Defining credit as a balance with a lifecycle made several downstream features fall out naturally instead of being designed separately.
Policy belongs in the product
Encoding finance rules into the system removes discretionary decisions and makes outcomes consistent and auditable.
Facing workflow complexity that slows growth?
Most SaaS product challenges originate in workflows, operational constraints, and business processes — not interface design alone.
We help teams identify structural product issues before they become expensive development, reporting, or financial control problems.
No long-term commitments. No generic frameworks. Just clear direction.