Skip to content

Exception management

Merchant settlement exception dashboard

Track delayed, failed, mismatched, and reconciled settlement states from one operator-friendly dashboard instead of rebuilding the story by hand.

Settlement exceptions create support load because the payment record, the customer conversation, and the finance workflow often live in different systems. A merchant settlement exception dashboard gives teams one place to understand what went wrong, who owns the next action, and which invoice, order, or payout record is affected.

Which exceptions matter most

The goal is not to surface every backend event. The goal is to surface the exceptions that change what support, finance, or product teams need to do next.

  • Delayed settlement where payment capture succeeded but payout is still pending
  • Failed settlement where funds need a retry, reroute, or manual intervention
  • Mismatched records where invoice, payment, and payout references do not line up cleanly
  • Reconciled states where the exception is resolved but history still matters

What a good dashboard clarifies

An exception dashboard should reduce ambiguity, not add noise. Teams need ownership, timeline, and business context first.

  • Which commercial record is impacted
  • Which visible state the merchant or buyer is currently seeing
  • Who owns the next step across support, finance, and operations
  • What changed over time so the team can explain the outcome later

Why teams use Hanko for this workflow

Hanko combines proposals, agreements, invoices, and client-facing payment surfaces, which makes it easier to keep exception handling attached to the same workspace as the commercial record.

  • Preserve invoice and client context alongside settlement updates
  • Reduce support loops caused by conflicting status surfaces
  • Keep exception handling readable for customer-facing and operator-facing teams alike

Frequently asked questions

What is a merchant settlement exception dashboard?

It is an operator-facing dashboard that shows the exceptions that interrupt normal settlement flow, such as delays, failures, mismatches, and manual reviews.

Why separate payment capture from settlement exceptions?

Because a payment can appear complete to the buyer while merchant-side settlement or reconciliation still needs attention. Those are different operational states.

Who should own settlement exceptions?

Ownership usually spans support, finance, and operations. The dashboard should make that handoff explicit instead of forcing teams to guess.

Can this dashboard support both fiat and crypto settlement paths?

Yes. The operational need is the same: keep exceptions attached to the same business record regardless of which rail the payment or payout used.

Next step

Turn exceptions into a manageable workflow

Use Hanko to keep merchant communication, invoice context, and settlement follow-up inside one workspace.