外掛標籤
開發者團隊
② 後台搜尋「ThemeChum Checkout Monitor for WooCommerce」→ 直接安裝（推薦）
原文外掛簡介
Your homepage loads. Your ads are still spending. Your uptime monitor is green. And nobody has bought anything for six hours, because the checkout is throwing an error that only appears at the payment step.
That is the outage nobody catches. A broken checkout does not look broken from the outside. Everything that normally tells you something is wrong keeps saying everything is fine, because none of those tools ever tries to actually buy something.
This plugin fixes that. Together with the Checkout Monitor service it places a real, complete test order on your store on a schedule — add to cart, checkout, simulated payment, order created — and emails you when a step stops working. By default we alert after two failed checks in a row, so a single network blip does not wake you up. That means you hear within about two check intervals of the break (within about six minutes on a 3-minute interval, up to an hour on the free plan’s 30 minutes), not when you check your sales figures the next morning. If you would rather hear after the first failure, you can lower the threshold to one check on your store’s Edit page.
And it does this without touching your real business data. Every test order is flagged and kept out of WooCommerce Analytics and your transactional emails, and on stores using High-Performance Order Storage (HPOS) it is hidden from your orders list and order counts as well. Your reports stay clean. Your inbox stays quiet.
What you get
A real test checkout, start to finish, on your own store — not a ping, not a page load, an actual order going through the same path a customer takes.
An alert when checkout fails two checks in a row, or on the first failure if you lower the threshold, with the error and a plain-English explanation of the likely cause.
A second alert when it starts working again, so you know it is genuinely fixed.
A warning when your storefront is hidden behind a coming-soon or maintenance page, so you find out before a day of traffic hits a splash screen.
A check on whether your order-confirmation emails are even configured to send, so a broken SMTP setup shows up before a customer complains that no receipt arrived.
Test orders kept out of Analytics and every WooCommerce email, and hidden from the orders list and status counts on HPOS stores.
Why uptime monitoring is not enough
An uptime monitor asks your server whether a page loads. It does not add to cart, it does not submit a payment, and it does not create an order. A plugin conflict on the checkout page, a shipping or tax rule that throws an error, a fatal error that only fires when an order is written, a coming-soon page left switched on — every one of those leaves an uptime monitor perfectly green while your store takes no orders at all. The only way to know checkout works is to complete a checkout.
How it works
1. Install this plugin on your store. It generates a shared secret automatically when you activate it.
2. Paste that secret into your Checkout Monitor dashboard at checkoutmonitor.app, along with your store URL.
3. Choose how often to test. That is the whole setup. Checkout Monitor starts running test checkouts on your schedule and alerts you when one fails.
Security and privacy
The technical detail, for anyone who wants it before installing something that can place orders on their store.
Every incoming request is verified with an HMAC signature, a timestamp and a single-use nonce, so only Checkout Monitor can trigger a test. Any mismatch is refused with an identical response, giving an attacker nothing to learn from.
The test product is hidden from your catalog, your search results, the Store API, the classic REST API and the admin product list. Only the verified bot can see it.
The test payment gateway is available only to the verified bot. It never contacts Stripe, PayPal or any real payment provider, and no money ever moves. Real customers cannot see or select it, whatever the enabled toggle in WooCommerce says — availability is decided per request by the signature check.
Every test order is flagged at creation and suppressed across WooCommerce Analytics and all transactional emails, including the admin new-order notification. On stores using HPOS it is also hidden from the orders list and the status counts; see the HPOS question in the FAQ.
A signed cleanup endpoint deletes old test orders. While your store is connected, Checkout Monitor calls it every hour to remove test orders older than 24 hours.
What it does not do
It does not take payments, and it does not place orders for real customers.
It does not modify your theme, your checkout page or any of your existing products.
It does not send any of your data anywhere on its own. See External services below.
A Checkout Monitor account is required, because the service is what runs the checks. You can create one from Settings → Checkout Monitor on your own site, or at checkoutmonitor.app. The free plan does not expire and does not ask for a card.
External services
The plugin is inbound by default. It exposes three authenticated REST endpoints that the Checkout Monitor service at checkoutmonitor.app calls, authenticated with a shared secret that lives on your own site. Every request without a valid signature is refused.
There is exactly one outbound path, and you start it: Create account on Settings → Checkout Monitor. It sends two things, at two moments:
When you press Create account — your name, email address and the password you typed, over HTTPS to https://app.checkoutmonitor.app/api/register. That creates the account; we email you a confirmation link.
Once you open that link — this site’s URL (its WordPress home URL) and its shared secret, to the same service, so the store is added and monitoring can begin. The secret is the one this plugin generated; you never have to copy it anywhere.
While setup is in progress the plugin keeps your access token encrypted on your site and checks whether the email has been confirmed. As soon as the store is added, the token is revoked and deleted — after that the plugin holds no session at all, and goes back to answering signed requests only. Nothing else in the plugin contacts an external service: there is no background call, no scheduled call and no call on activation.
Data your store returns when the service calls, and only then:
Status endpoint — whether your WooCommerce order-confirmation emails are enabled, the admin notification recipient address, your store’s “from” email address and name, a hint identifying which SMTP plugin is active (if any), and the timestamp of the last plugin, theme or core update. The two email addresses are the only personal data involved; they are needed so the service can tell you whether order emails are actually configured to reach anyone.
Payment health (1.2.0) — for each payment gateway on your store: its id, whether it is enabled, and whether it is available right now. Plus whether an enabled shipping method covers your store’s own base country, whether the checkout page uses the block or shortcode checkout, and which of those gateways are offline methods (cash on delivery, bank transfer, cheque). No settings values, no keys, no customer or order data. This exists because our test order pays through a test gateway only our bot can use, so a passing check would otherwise say nothing about whether a real customer can pay.
Order counts (1.2.0) — three numbers and a timestamp: how many real orders your store took in the last hour, the last 24 hours and the last 7 days, and when the most recent one came in. Orders created by this plugin’s own test checkouts are excluded. No order contents, no customer names, no addresses, no products. The counts exist so the service can tell you when a shop that normally sells at this hour goes silent — the one failure that no page-load check can see.
Test product endpoint — the id, slug, SKU, permalink, status and visibility of the hidden test product.
Cleanup endpoint — the number of test orders removed and the number remaining. It requires an explicit confirmation flag in the request body and only ever touches orders this plugin created.
Your customer records, order contents, payment details and site credentials are never read or returned by any of these endpoints.
Using the Checkout Monitor service is subject to its Terms of Service and Privacy Policy.
