Integration reference
Payment health dashboard model
Role-oriented dashboard concepts for finance, integration, support, treasury, and executive views—anti-patterns for single-plane dashboards.
01
Purpose
Internal dashboards should be role-oriented—not one chart for every team. This model lists questions each view must answer and anti-patterns that hide operational risk.
02
Role-oriented views
No live dashboard is hosted on this site; use this as a design checklist.
| View | Must answer | Key signals | Anti-pattern |
|---|---|---|---|
| Finance | What is books-ready vs detected? | Drift, exception depth, checkpoint lag | Single paid flag drives GL posting |
| Integration engineer | Are webhooks verified and recent? | Webhook recency, provider latency | 200 OK without idempotency visibility |
| Support / operator | What state can support quote? | Checkpoint lag, exception queue | Chat overrides without exception record |
| Treasury | What is recognized vs in-flight? | Payout backlog, ledger drift | Payout queue without ledger context |
| Executive health | Which incident classes are degrading? | Trends you define; class counts | Vanity uptime without taxonomy |
03
Dashboard integrity
Never collapse commerce, provider, and finance planes into one indicator. Never publish fake SLA percentages on public marketing surfaces—track thresholds internally.
- Retries are normal. Webhook delivery is at-least-once. Design consumers to tolerate duplicates and out-of-order arrivals where possible.
- Asynchronous by design. Payers, chains, and your servers operate on different clocks. UI and finance should not assume synchronous finality.
- Eventual consistency. API reads, webhooks, and portal views may briefly diverge during transitions. Reconciliation jobs exist to converge truth.
Walkthroughs: /operations