Privacy

This service is built so that the data it would be embarrassing to hold never arrives in the first place.

What a connected store sends

• Counts of orders by status, per hour
• How long orders take to move from one status to the next, as a median and a 90th percentile
• Order-note reason codes, from a fixed list of nine (insufficient funds, authentication failed, gateway timeout, authorized not captured, webhook missing, duplicate callback, address or AVS rejected, risk blocked, unknown)
• Whether each gateway is enabled, available, and in test mode
• Webhook topics with success and failure counts and a status class (2xx / 4xx / 5xx)
• Scheduled-action backlog for checkout-related hooks
• Which plugins, themes or core versions changed recently, and between which versions
• Whether the checkout page is assigned, published, and contains a checkout block or shortcode — read from the store's own database, never by loading the page
• Which signal families this store can and cannot report, so an empty list is never mistaken for a healthy one
• WordPress, WooCommerce and PHP versions

What is not collected at all

Error logs. A PHP or WooCommerce log line is a strong diagnostic signal and is also the single most dangerous thing to read: third-party gateway plugins write payment identifiers, customer email addresses, absolute paths and whole API responses into them. Normalising arbitrary text from software this project does not control cannot be proven safe, so none of it is read. The field is empty by design and every answer says so, rather than letting an empty list read as "no errors". What that costs.

What is never collected

No customer name, email, phone, address or IP. No order numbers, order contents or purchase history. No card details or payment method information. No payment intent, charge, customer, session or transaction identifiers. No API keys, cookies, nonces or authorization headers. No webhook URLs, secrets or bodies. No log files or database dumps. No wp-config values, absolute paths or table prefixes.

This is enforced twice: the plugin never reads those values, and the service scans every arriving snapshot and refuses the whole request if one is present. A refused snapshot is not cleaned and kept — accepting a scrubbed version would teach the sending plugin that identifiers are acceptable.

The refusal returns a code and nothing else. Telling the sender which field looked like an email address would itself be a description of the merchant's data.

Order notes

Order notes are where a payment failure explains itself, and also where a customer's name or email is most likely to appear. The note text is classified into one of the nine labels above on the store and then discarded. The text never leaves the site, and the snapshot reports how many notes were dropped so the count is not silently lossy.

Buckets, not moments

Counts are aggregated into hourly or quarter-hourly buckets, and a change's timestamp is bucketed rather than exact. A bucket containing one order is a bucket that could be narrowed to one customer; the aggregation is what stops that.

Connecting, and stopping

The plugin makes no outbound request at all until an administrator explicitly connects the store. Disconnecting removes the schedule and the stored secret together, and deleting the plugin removes both as well.

What this service does not do

It does not read your orders, customers or payment records — it has no credential that could. It does not modify anything. It does not sell data.