Platforms
One monitor, wherever you sell
The same rules, the same alerts and the same reporting on every platform. What changes is the connector that reads your store — and how much each platform is willing to tell it.
Where it runs
The connector is built, tested and running — the app is with Shopify for App Store review, which is a queue we do not control. It will install in one click from the App Store the moment it is approved.
If you sell on Shopify and want it sooner, tell us and we will let you know the day it is listed.
- Install
- One click, once listed
- Permissions
read_orders, nothing else- Billing
- On your Shopify invoice
- Status
- Submitted for review
- History read on install
- 60 days
Available today
These three you can connect right now. Same rules, same alert lifecycle, same reporting as Shopify will have — and they connect with read-only credentials you generate in your own admin, with no plugin to install.
Connect with a read-only store API token. Their Transactions API reports gateway, status and transaction id per payment, so every rule works exactly as it does on Shopify.
Connect with read-only REST API keys from your WordPress admin. Monitoring runs on our servers, so it keeps working on a quiet store where WordPress’ own scheduler would not.
Shopware
Connect with an integration’s client id and secret. Shopware keeps a state machine on every payment and every refund, which is exactly the second record this product exists to read.
What each platform records
How much we can see depends on your platform
Every platform keeps the refund and the payment that fulfils it as two separate records. What differs is how much the platform is willing to say about the second one — and that decides what we can catch.
| Platform | How you connect | What it lets us see |
|---|---|---|
| Shopify | One click from the App Store. Read-only, orders only. | The most of any platform. Every refund carries the gateway’s own record of what happened to it — paid, failed, or still pending — with the reference the gateway gave it. |
| BigCommerce | A read-only API token you generate in your own admin. | The same shape. Each payment and refund reports its gateway, its status and its transaction reference, so every rule works here unchanged. |
| Shopware | A read-only integration you create in the admin. | A refund carries a status of its own, tracked apart from the order’s. A refund can sit at failed while the order still reads as refunded — which is this product’s whole subject, stated by the platform itself. |
| WooCommerce | Read-only API keys from your WordPress admin. No plugin. | Less, and we would rather say so. WooCommerce keeps no gateway status per refund, so what we watch here is refunds recorded with no money behind them, and payments left stuck or failed. |
Why WooCommerce is the honest exception
On Woo, a gateway refund that fails usually errors at the moment someone presses the button, and no refund record is written at all. There is less for us to find afterwards, because less was recorded. So most of the value on WooCommerce sits on the payment side instead: orders stranded in pending or on-hold, and payments that failed outright.
That is also why monitoring runs on our servers rather than inside WordPress. WordPress only runs its own scheduled jobs when somebody visits the site, so a quiet store — exactly the store where a stuck payment goes unnoticed longest — would never be checked at all.
One product, not four
The detection rules, the alert lifecycle and the reporting are written once and shared by every platform. A connector translates your store’s vocabulary into the one the rules already speak; nothing downstream of it knows or cares which platform you are on.
It is called Order Exceptions rather than something narrower for the same reason. A failed refund is the first thing we watch, not the last.
Connect a store
Shopify installs from the App Store. Everything else connects with read-only credentials you generate yourself, in about the same minute.