Why acquirer problems are usually caught too late
When an acquirer degrades, the first signal is usually a merchant complaining about conversion. By the time that complaint arrives, you have already lost a morning of volume and some trust. Monitoring is part of the omwio platform, built into the tenant manager, to close that gap and let operators see degradation before merchants do.
Signals at the level routing actually decides on
Monitoring tracks success rates, latency and error mix per provider and per MID — the same level that routing decisions are made at, rather than one global number for the whole platform. That granularity matters: a problem on one MID can be invisible in an aggregate view while it is already hurting conversion for the merchants routed to it.
Alerts that point at a route, not just 'something is wrong'
Alerts in Monitoring are route-aware. Instead of a generic warning, an alert points at the specific route that is failing, so the response can be concrete: move this method to the backup MID. Outbound notifications render through the same branded mail layer as the rest of your tenant e-mail, so they arrive looking like your platform, not a bolted-on third-party tool.
What this changes for merchant operations
- Detection ahead of complaints: you open the conversation with your merchant, instead of answering it.
- Faster failover decisions: a signal tied to a specific MID is directly actionable against the routing rules you already have.
- Evidence for provider conversations: degradation over time is recorded, which turns an acquirer negotiation from anecdote into data.
Availability
Monitoring is enabled per billing plan, with access enforced both in the tenant manager navigation and at the API route level.
