The dashboard must show where deposits are lost
A payment dashboard is a control surface, not a volume report: show whether a lost deposit came from issuer behaviour, PSP outage, routing, avoidable retry, KYC friction, or cashier abandonment. One success rate reveals a problem, not its owner or fix.
In iGaming, failures waste acquisition spend, delay activation, suppress repeat deposits, and generate support contacts; slow withdrawals damage trust. Keep deposit and payout health separate. This blueprint covers definitions, formulas, cuts, and scorecard logic—not orchestration architecture or PSP selection.
A status model decides whether approval means anything
Define one lifecycle across cards, wallets, bank transfers, and local methods. Provider statuses differ: card authorisation can precede settlement, while account-to-account payment may be reliable only after a confirmed callback. Treating raw statuses as equivalent creates false precision.
Use mutually exclusive terminal states for each eligible attempt—one reaching routing after internal validation. Exclude page views, abandoned cashier forms, blocked territories, and duplicate telemetry. Keep risk blocks and KYC holds separate; counting them as PSP declines hides product or compliance constraints in a supplier metric.
| Metric | Formula | Decision use |
|---|---|---|
| Approval rate | approved eligible attempts / all eligible routed attempts |
Deposit conversion by route, method, and cohort. |
| Decline rate | issuer or provider-declined attempts / all eligible routed attempts |
Separates negative responses from technical loss. |
| Technical failure rate | timeouts, integration errors, unavailable routes, or malformed requests / all eligible routed attempts |
Identifies routing, PSP, or integration reliability. |
| Pending rate | attempts without a terminal state inside the agreed window / all eligible routed attempts |
Exposes delayed callbacks, reconciliation gaps, or manual queues. |
| End-to-end approval rate | (first-pass approvals + retry approvals) / retry-eligible first attempts |
Customer outcome after the approved retry policy. |
Declare an observation window: a wallet payment pending at hour one and confirmed at hour six is not failed because the dashboard refreshes hourly. Maintain real-time incident views and settled, reconciled finance views for cost and revenue.
Record attempt ID, parent payment journey ID, player ID, timestamp, GEO, currency, method, PSP, acquirer or route, issuer-response family where available, internal risk outcome, final state, and amount. The parent journey ID links post-decline attempts; treating them as separate opportunities overstates failure and hides retry behaviour.
Retries can inflate a weak route
Retries may improve end-to-end approval while making a weak first route look acceptable. They can add latency, duplicate support contacts, payment cost, or an account-takeover signal. Show the sequence rather than reward a rule for repairing damage it created.
Define retry eligibility before recovery calculations. Depending on method rules and risk policy, include technical failures, soft issuer declines, or route timeouts; exclude hard declines, blocked accounts, withdrawals, and attempts breaching local rules or customer-communication standards. Eligibility is a product and risk decision, not reporting convenience.
Use these measures together:
- Retry rate =
retried eligible journeys / retry-eligible first attempts. - Retry recovery rate =
journeys approved after a retry / retried eligible journeys. - Retry uplift = end-to-end approval rate minus initial-pass approval rate, in percentage points for the same retry-eligible cohort.
- Retry cost per recovered deposit =
incremental retry processing cost / journeys approved after retry.
Retry uplift is association, not proof that retries caused every recovered approval. Cohorts can differ by traffic source, bank, hour, deposit value, or player persistence. Compare the same route and segment before and after a routing-policy change; inspect technical failures, decline codes, complaints, and duplicate-payment rates. Higher approvals with more duplicate tickets shift cost into operations.
Different teams need different payment cuts
An executive view may show approval, payout latency, payment cost, and unresolved exceptions, but cannot diagnose alone. The working dashboard needs shared definitions and segmentation.
For segment s, approval is approved attempts in s / eligible routed attempts in s. Portfolio approval is total approvals / total eligible attempts; never average segment rates, which gives low-volume routes equal weight. Compare against its own baseline—same weekday, hour band, method, and currency. A sharp mobile-wallet decline during one issuer incident differs from a gradual decline in an affiliate cohort.
Start with decision-linked cuts: method, PSP and route, GEO, currency, device, first versus repeat depositor, new versus returning player, amount band, hour, and acquisition source. Add issuer or bank group only when data is reliable and privacy governance permits. Fifty filters are useless if no route change is identifiable.
Lifecycle cuts matter. First-deposit approval measures activation friction and cashier trust; repeat-deposit approval measures retained convenience, saved-method performance, and loyalty risk. Split payout latency into requested withdrawal, compliance review started, approved, released to PSP, and player-confirmed completion. One average hides whether delay is internal review, provider queue, or payout rail.
A PSP scorecard should expose margin and trust
Do not rank PSPs on approval alone. More accepted deposits may come with higher cost, volatile failures, or delayed payouts that reduce contribution margin or confidence. Show trade-offs, eligible volume, and data state.
| Scorecard field | Calculation or evidence | Why it changes a decision |
|---|---|---|
| Deposit approval | Approved eligible attempts / routed attempts | Conversion after routing. |
| Technical reliability | Technical failures and pending rate, with incident timestamps | Separates declines from service reliability. |
| Recovery contribution | Approved retry journeys / retry-eligible journeys | Whether failover repairs meaningful loss. |
| Cost per successful deposit | PSP, routing, FX, and method charges / approved deposits | Prevents approval gains hiding margin leakage. |
| Payout latency | Median and p90 from approved withdrawal to player-confirmed completion | Shows routine experience and complaint-driving tail. |
| Reconciliation quality | Unmatched or late-settled transactions / processed transactions | Finance workload and reporting risk. |
| Risk burden | Fraud flags, chargebacks, manual-review load, and false-positive evidence | Prevents exporting loss to risk teams. |
Match cost to the question. Routing uses processing, FX, route, and method charges. Contribution analysis may add chargebacks, bonus effects, taxes, and provider costs, but must not call that wider measure “PSP cost.” Clear boundaries avoid arithmetic disputes.
Use percentiles, not only a payout mean: stalled withdrawals can leave an acceptable average but severely harm trust. P90 captures the slow edge of normal operations. Keep AML investigations or missing documents in a labelled separate queue. Removing them overstates speed; mixing them into ordinary payouts wrongly blames the PSP for internal controls.
Scale turns routing into an attribution problem
At low volume, support tickets and a daily PSP export can expose outages. As routes, currencies, and methods grow, attribution is the constraint. A transaction can appear in cashier events, orchestration, PSP feeds, bank statements, fraud tools, and finance ledgers. Without stable IDs and timestamp rules, approval rates drift and incident reviews become data disputes.
The hardest failures are not outages. A route can retain respectable portfolio approval while losing first-time mobile users in one currency; fallback can recover deposits only after an unclear error makes players leave; a method can seem cheap until reconciliation, support, and slow payouts are included. The effect exists, but reporting assigns it to the wrong layer.
Maintain route history rather than overwrite it: preserve originally selected route, every failover destination, retry reason, policy version, and final outcome for each attempt. Annotate routing-rule deployment times, or teams may mistake a configuration release, payday pattern, or marketing burst for supplier change.
Data retention, consent, AML controls, and responsible-gambling suppression rules determine what can be joined and who can see it. Licensing and privacy requirements vary by GEO. Validate player-level payment signals for CRM or personalisation with compliance and data-governance owners.
Build an operating cadence before automation
A mature dashboard has owners and preset responses. Payments owns route health and supplier escalation; product owns cashier messaging and fallback experience; risk owns eligibility and review effects; finance owns settlement and cost reconciliation; analytics owns definitions, data QA, and change logs. Shared visibility does not remove accountability.
Alert on rate movement and absolute impact. A small dip on a low-volume route may not warrant a page; the same dip on a dominant first-deposit method can threaten acquisition payback within hours. Include a minimum attempt count, comparison baseline, and route-level impact estimate. Automatic rerouting needs guardrails for cost, fraud exposure, payout capability, and duplicate-processing risk.
Use weekly reviews for persistent deterioration, cost drift, long-tail payout latency, reconciliation exceptions, and retry behaviour. After material disruption, review detection time, affected segments, routing response, player communication, reconciliation impact, and permanent fix. Value is decision speed and discipline, not visual polish.
A payment KPI becomes useful when it changes a route
Approval is a customer outcome, not a score to maximise at any cost. The strongest dashboard traces a player attempt to final state, the cost of recovering failed journeys, and the withdrawal experience that determines whether trust survives.
Build the data contract first, then route and segment views, then scorecard and alerts. If a metric cannot identify an owner, decision, and guardrail, keep it in a data-exploration workspace rather than the operating dashboard.