eCommerce.In build

Decide whether to probe at all. If WooCommerce is not active, if the site is already down, or if a previous probe order is still open, it exits here and creates nothing.

Which payment gateways are actually switched on, whether shipping zones still cover where the store sells, whether a database update is pending, and how deep the background job queue is. Most broken stores fail here and never reach step four.

Record the exact stock level, order number and queue depth it is about to move, so the cleanup is precise rather than best effort. Nothing is created until that record exists.

Adds a hidden, virtual probe product to a fresh cart and completes checkout through the store own pipeline, with its own tax and shipping rules, paid by a method that exists only while the request is running.

The order exists, it has the right status, stock moved the way it should have, and the confirmation email left the site.

Cancels, restocks and removes the probe order and everything it created. Runs whether the probe passed or failed, and says so loudly if it cannot finish.

Stock, order sequence and queue depth back where step three recorded them. Any drift is reported rather than swallowed.

Not that checkout failed, but that checkout has been failing since 06:12 and this store took a known amount in the same window last week. Totals only. It never reads a real order or a real customer.

Every gateway WooCommerce lists, which of them are enabled, and which ones the checkout page actually offers a customer.

Where a gateway publishes a credential test, Protuno calls it and reports the provider's own answer. Nothing is charged and no card is used at any point.

A gateway left in test mode, or enabled with sandbox credentials after a migration, is the commonest silent way a store takes no money.

Request the gateway endpoint from our network and record the status and the time it took. A gateway that times out breaks checkout the same way a wrong key does.

It proves the store can talk to the provider with the credentials it holds. It does not prove a real card would be accepted, because nothing here charges one.

Ordered by how much of the checkout each finding blocks. It changes no setting on the store and none at the provider.

Totals by order status for the last day and the four weeks before it. Counts only. It never opens an order and never reads a customer.

Every store fails some checkouts. The number worth alerting on is the change from this store's own baseline, not the raw figure.

Counts per gateway, never the orders themselves. A rate that moves on one method and not the others names the cause on its own.

The hour the rate crosses the band, not on the next scheduled report.

Not that failures are up, but that failures are up eleven points since 06:12 and this store took a known amount in the same window last week. Totals only.

It reads totals. It cancels nothing, retries nothing and changes no order.

How many orders are pending, on hold or failed, and how old the oldest of each is. Counts and ages only.

A pending order twenty minutes old is a customer still typing. One four days old is money that never landed.

A pile of pending orders is usually the provider's callback not arriving. Request the callback address and confirm it answers and rejects an unsigned request.

Whether the scheduled action that moves an order on from pending is still running, because a stalled queue looks exactly like a stalled gateway.

A blocked callback address, a scheduler that stopped, or a gateway failing to confirm. Each one is a different fix.

Ages, counts and the endpoint to fix. It never opens an order, never reads a customer and never changes a status.

Every product with stock management on, its level, its backorder setting and its low stock threshold.

Products with stock management switched off, or backorders quietly allowed, sell past zero and nothing warns anybody.

Where a stock system is connected, hold its figure against the store's. A drift of one is a returns process. A drift of forty is a broken sync.

The last time it completed, because a sync that stopped last Tuesday looks identical to a sync that works.

A product that can oversell only matters in proportion to how often it sells.

It reads levels and reports drift. It never writes a stock number, in either direction.

List the products out of stock past the window you set that still sit in the sitemap and still take search traffic. If there are none it exits here and creates nothing.

Record the catalogue visibility, the stock status and the address of every product it may touch, so the change can be put back exactly. Nothing is edited until that record exists.

The list, the proposed action for each product and the replacement page you chose. There is no timeout and no default yes.

Hide the product from the catalogue, or send its address to the replacement you picked. One product at a time, through post revisions.

Restores every product to the visibility and the address step two recorded, in one action. No product is deleted at any point.

Request each changed address and confirm it answers the way you asked for, and that nothing else in the catalogue moved.

Every shipping zone, the regions inside it, and the methods inside each one.

The countries the store's own selling settings allow. Anywhere allowed but not covered is a checkout that offers nothing at the last step.

A zone with no method in it, and a rest of the world zone that does not exist, both end the same way for the customer.

Run the store's own shipping calculation for each uncovered region and record what comes back. It creates no cart and no order.

The regions, the missing methods, and the zone each one should sit in. It edits no zone and no rate.

Whether tax is on, whether prices are entered with it or without it, which address the rate is based on, and the rounding rule.

Every rate, its country, its class, and any row sitting at zero that looks like it was left half finished.

A shipping zone with no matching tax rate collects nothing in that region, and the shortfall is only visible at the year end.

Price a basket through the store's own calculation and hold the tax it returns against the rate the table says applies.

A rate table that moved without a release behind it is worth a question the same week, not the same quarter.

The finding and the setting to change. It never edits a rate, because getting tax wrong is expensive in both directions.

How many actions are pending, how many are running, and how long the oldest one has been waiting.

Failed actions counted by what they were trying to do, rather than listed one at a time.

Completed actions in the last hour against the same hour last week. A queue at zero throughput is a stopped store with a working homepage.

Whether the queue runs on the site's own scheduler, and whether that scheduler is being reached from outside at all.

Not that the scheduler is behind, but that order confirmation emails have not been sent since 03:40.

It reads the queue. It does not retry, cancel or delete an action, because a retried action can send a second email to a real customer.

Read the store's schema version against the plugin version. If no update is pending it exits here and changes nothing.

Which tables the update touches and roughly how many rows, so the length of the job is known before it starts rather than halfway through.

A full database backup labelled for this run, confirmed readable. No row is migrated before this succeeds.

Through WooCommerce's own updater, one batch at a time, with the shop page, a product and the cart requested after each.

If a batch errors, or the checkout stops answering, the database goes back to the backup from step three immediately and the run stops there.

Schema version current, the shop, a product, the cart and the checkout all answering, and the background queue draining again.

What was migrated, how long it took, and the backup it can still be rolled back to.

Every WooCommerce template the theme or a child theme carries its own copy of.

The version header on each copy against the version the plugin ships today.

The lines the plugin added since that copy was made, so the finding is a difference you can read rather than a version number.

An out of date checkout template is money. An out of date product tab is not, much.

It reads files. It edits no template, because an override is somebody's deliberate work and overwriting it breaks the design.

Whether the cart fragments request is enabled, and which templates ask for it.

Request the endpoint the way a browser does and record how long the server took to answer, measured from our network.

It is only expensive where there is no cart. Request a sample of templates and record which ones call it anyway.

Whether the cache or the CDN passes it straight through, which it must, and whether anything else has been made uncacheable alongside it.

The measured time and the pages it runs on, not a grade out of a hundred. It changes no setting.

Read the product structured data from a sample of product pages exactly as they are delivered.

Required fields present, types correct, and the offer block complete rather than half filled.

Price, currency and availability in the markup against what WooCommerce holds right now. A sold out product still marked in stock is a click somebody pays for and wastes.

Two plugins each writing their own product block is one page described twice, and the search engine picks one of them without telling you which.

Ordered by what the product sells, with the field to change. It publishes nothing and edits no page.

The base currency, its symbol position, its separators and how many decimal places it uses.

Every enabled payment method and the currency each is configured to accept. A gateway that cannot take the base currency fails at the last step of checkout.

The currency in the product schema and in any connected product feed against the base currency the store charges in.

If a multi currency plugin is installed, whether every currency it offers has a rate, a rounding rule and a gateway that accepts it.

Each mismatch and where a customer would see it. It changes no price and no exchange rate.

Read every coupon, its expiry, its usage limit and how often it was redeemed in the last month. If nothing is open past its campaign it exits here and changes nothing.

A code with no expiry and no limit that is still being redeemed is money leaving the business. A stale code nobody uses is housekeeping.

The exact expiry date and usage limit on every coupon it may touch, so any change can be put back to the value it had.

The list, with the date proposed for each code. Nothing is changed until you approve it, and there is no default yes.

One coupon at a time, the expiry date only. No coupon is deleted, and no discount already applied to an order is altered.

Restores every coupon to the values step three recorded, in one action.

Read each coupon back and confirm it holds the date you approved and nothing else moved.

Renewals scheduled for today and for the week, as totals by status. Counts only, never a customer and never an order.

A renewal with no scheduled action behind it will never run, however healthy the subscription looks on screen.

Failed and on hold renewals for the period, grouped by payment method and by the reason the gateway gave.

How many stored payment methods expire inside the next two months, as a number. It never reads a card and never reads a customer record.

The figure that matters is the change in the failure rate, because every subscription store has a floor it never gets under.

The value at risk in the window, from totals alone. It retries nothing, cancels nothing and emails no customer.

Check WooCommerce is active, the store is answering, and no earlier probe is still open. If any of that fails it exits here and creates nothing.

Record the stock level, order sequence and queue depth it is about to move, so the cleanup is exact rather than best effort. Nothing is created until that record exists.

A hidden virtual product bought twice through the store's own pipeline, paid by a method that exists only while the request is running. No real payment processor is charged.

Run the store's own cancellation path and its own refund path against the two orders this run created, and record exactly what each returns.

Statuses changed, stock came back, and the emails the store sends on a refund and on a cancellation left the site.

Removes both probe orders and everything they created. Runs whether the probe passed or failed, and says so loudly if it cannot finish.

Stock, order sequence and queue depth back where step two recorded them. Any drift is reported rather than swallowed.

Whether a refund can be issued today, and the exact error if it cannot. It never reads, refunds or cancels a real order.