Sign in required

Baseline volume + first-attempt approval per PSP in the current 30-day window across the 8-merchant GetNet cohort. Use as the denominator when reasoning about any lift/drop below — a 5pp gap means very different things at 100k tx vs 500 tx.

The routing-decision oracle. Any hard-coded override candidate for the router should be grounded in a row from this table with n ≥ ~500 for signal. Sortable by clicking column headers.

Filter by PSP to isolate a single processor's decline mix. Category tag rolls each ISO 8583 code into one of: bank_rejected, fraud_bank, insufficient_amount, psp_int_settings, user_settings, other.

"What % of prosa's declines are fraud vs technical vs invalid-card?" — the rollup of the top-codes view. Useful for spotting PSPs with an anomalous category mix.

Diagnostic view — when a (PSP × Brand) slice under-performs, this table shows which decline codes are driving it. Different codes imply different fix paths (fraud rule vs invalid-card handling vs …).

"When PSP_X declined an order, did retrying on PSP_Y approve?" All save rates currently sit under ~5%, which supports the argument that declines are legitimate customer/card issues (bad funds, real fraud, dead cards) rather than PSP flakiness. High save rates (>5%) would argue for retry logic.

Codes seen on 2+ PSPs. Heavy per-PSP skew (e.g. code 79 is 100% getnet, code 83 is 94% getnet) reveals that the same ISO 8583 code maps to PSP-specific behavior — a hint the PSP is either mis-issuing the code or routing a specific issuer pattern our way.

Jira-ready markdown output from the upstream analyzer. Paste into ATH-1529 or a Slack thread when reporting findings.