Payments dashboard UX: make every payout explainable
A worked payout example helps payments teams evaluate whether a merchant dashboard explains the numbers and leaves unresolved differences visible.
Fintech and banking
Published Updated 6 min read
Imagine a merchant opening a payments dashboard before a call with finance. Sales show $12,000. The bank received $9,480. Both numbers might be correct, but the dashboard leaves someone with an awkward question: where did the rest go?
A useful payments dashboard lets that person trace the difference to specific records, then decide whether anything needs attention. When choosing a design agency for a payments company, ask it to demonstrate that journey. A polished revenue chart reveals much less about how the team handles a merchant’s working day.
The example below is hypothetical. It shows how to turn a confusing payout into a design brief and a practical test.
Which numbers should the dashboard compare?
Start by naming what each total means. Sales during a selected period, transactions included in a settlement batch, and money received in a bank account describe different things. A shared date filter can make them look comparable when they are not.
Choose one merchant account, one settlement currency, and one payout. Make that scope visible above the detail. Show the relevant dates with labels that explain the event, such as sale created, included in payout, or bank deposit recorded. Include the time zone where a cutoff affects the comparison.
Provider rules matter here. Stripe’s payout reconciliation report groups payouts by estimated arrival date rather than the date a bank posts the deposit. Its report data can also become available after the payout arrives. A missing breakdown therefore needs its own explanation; it is not evidence that the money is missing.
Before designing the screen, have the product and finance owners agree on the source of each number. The interface should expose the agreed calculation and its limits. It should not invent a cleaner financial model because that model fits the layout.
How can a merchant explain the $2,520 difference?
For this simplified example, all amounts are USD and belong to one merchant account. The selected sales period contains $12,000. Provider records confirm that $2,000 of those sales belongs outside the selected payout batch. The batch contains the remaining $10,000, with $220 in fees and $300 in refund debits. There are no other adjustments in this example.
| Record in the example | Amount | What the merchant should be able to open |
|---|---|---|
| Sales in the selected period | $12,000 | The included sales and the period’s boundaries |
| Sales outside this payout batch | $2,000 | Those transactions and their confirmed batch status |
| Gross sales included in this batch | $10,000 | The batch’s transaction list |
| Fees deducted in this batch | $220 | The fee entries behind the total |
| Refund debits in this batch | $300 | The refund records and original payment references |
| Expected payout | $9,480 | The complete calculation for this payout |
| Bank deposit matched to this payout | $9,480 | The bank record and the evidence used to match it |
The apparent $2,520 shortfall now has an explanation: $2,000 sits outside this batch, and $520 is accounted for by fees and refunds. The expected payout matches the bank deposit.
That explanation is the central design deliverable. Each adjustment must lead to evidence. A tooltip saying “Amounts may vary” would leave the merchant doing the same investigation in a spreadsheet.
Adyen’s transaction-level reconciliation guide describes matching transactions through provider and merchant references, then adding net credits and subtracting net debits to verify a batch payout. Use the actual provider records behind the product. Refunds, disputes, transfers, and other adjustments must appear when they exist; this example’s short list is not a universal payout formula.
Keep the sales-to-batch explanation separate from matching the payout to the bank. Explaining why a batch totals $9,480 does not prove that the bank received it.
What happens when the numbers still do not match?
Change one detail in the test: the bank record now shows $9,380. The remaining $100 is unresolved. The dashboard should preserve that difference until evidence explains it.
Give the user a useful investigation path. They should be able to check the account and currency, inspect the payout reference, review the source records, and see when the data last refreshed. If the bank match is only a suggestion, label it that way. Equal amounts alone should not silently settle the question.
Also distinguish “The records disagree” from “The report is not ready” and “The source could not be reached.” Those situations call for different next steps. Preserve the last confirmed information when a refresh fails, with a visible timestamp and explanation.
Payout mode can change the available evidence. Stripe’s reconciliation guidance explains that it cannot identify which transactions belong to a manual payout because the user controls its amount and timing. A design must not show an automatically confirmed batch breakdown when the provider cannot supply one.
If investigation requires another team, carry the payout reference, unresolved amount, source links, and current findings into the handoff. Decide with the product owners who can confirm a match or make a financial adjustment, and record those actions. A designer can clarify that process; the interface must not grant authority the user does not have.
How should a payments company test an agency’s proposal?
Use the worked example as a bounded, paid discovery exercise. Supply representative records and their definitions. Ask the agency to prototype the merchant’s route from the sales total to the payout explanation, then introduce the unresolved $100 variant.
Judge the proposal against observable outcomes:
- Can a merchant identify which sales belong to the selected payout and explain every deduction?
- Can they open the records supporting the explanation without losing the account, currency, or payout they were reviewing?
- Can they distinguish a confirmed bank match from a suggestion or missing data?
- Can they leave an unresolved difference with a named owner and enough context to continue the investigation?
Ask the agency to identify the data it needs before presenting screens. A credible proposal should name dependencies that could prevent the prototype from becoming a working product, including unavailable references or delayed reports. Request a comparable delivered workflow and confirm which parts the proposed team actually designed.
Humbleteam publishes this guide. Its fintech agency comparison provides starting points for provider research; apply the same exercise to every shortlisted team. For customer-facing transaction recovery, use the separate payment status guide.
What should the team take into development?
The finished brief should contain an agreed calculation, representative records, a prototype that exposes the evidence, and a tested route for unresolved differences. Finance and engineering should review the rules before implementation.
During testing, record whether participants explain the payout correctly, where they leave the interface to investigate, and whether they mistakenly close an unresolved case. Those observations give the team a baseline for later improvements. They do not require a promised conversion lift.
Return to the merchant before the finance call. They should be able to say why $12,000 became $9,480, show the records, and identify any amount that still needs investigation. That is a concrete outcome to put in a payments dashboard brief.
