Six areas, each with its own instrument
Processing, fraud, balances, payouts, integrations and the audit trail fail in different ways, on different timescales, and are noticed by different people. They are not one dashboard.
Processing, down to the attempt
Nine screens cover what actually happened at the provider: every charge attempt and every bank charge attempt, connection errors, the routing rules that fired, the raw request and response history, transaction history, pending events and the per-connector logs. When a merchant says a payment failed and the acquirer says it never arrived, this is the layer that settles it, because it holds the attempt rather than only the outcome.
Transaction managementTransaction monitoring that tells you
Write a rule against your acquirer traffic and it is evaluated as each decline arrives rather than on a schedule, so a provider going bad is caught inside its own sliding window instead of at the next scan. Rules are scoped to the provider and the condition you care about, the result is recorded so you can see what fired and when, and the action goes out as an email to the people who can actually do something about it.
Provider configurationFraud, with the reasoning shown
Fraud monitoring is three screens rather than one: the rules you wrote, the log of what they did, and the report that tells you whether they are still the right rules. Every hit records which rule matched and what it decided, so a blocked customer is a question you can answer in a minute, and a rule that is quietly blocking good traffic shows up as a pattern instead of as a slow leak in approval rate.
The risk rules engineBalance alerts that fire on the movement
Set a threshold per currency on one merchant, or once across every customer account in a programme, because configuring tens of thousands of accounts one at a time is not a workflow. The check runs at the moment the balance actually moves rather than on a timer, which is the only moment it can cross, so there is no periodic scan over your entire customer base and no window where the balance is low and nobody knows. A cooldown stops one crossing from becoming fifty emails, and lowering a threshold onto an account already beneath it raises the alert immediately rather than waiting for the next movement.
Balances and ledgerOn status changeReacts instantly
Scheduled sweepFires on silence
Payouts, where silence is the outage
Payout volume is low enough that a plain count threshold is the wrong instrument. Three requests this morning, all cancelled, then nothing at all is a broken corridor, and no rule that only wakes up when a fresh failure arrives will ever see it. So payout monitoring runs two ways at once: it reacts the moment a wire changes status, and it also sweeps on a schedule specifically so a rule can fire when nothing new has arrived. Alongside the familiar failure count there is a rule for the case that matters here, at least so many failures and not one success in the window.
Settlement and payoutsIntegrations and the audit trail
The remaining groups cover the edges where a platform quietly stops working for one customer while looking fine for everyone else. Every API call is logged with its request and response, so an integration argument is a lookup. Outbound webhooks record what was delivered and what failed. Requests for information sit in their own queue rather than in somebody's inbox. Account status changes are attributed to a person and a time, and you can see who is logged in right now.
Reporting and analytics
