A customer pays for an order, but their course access never arrives. A parcel is ready, but the fulfilment system has no record of it. The checkout worked; the business workflow did not.
WooCommerce automation testing means following an order beyond payment and checking the result in every connected system. This guide helps business owners plan that test, spot common gaps and give a developer a clear brief. Official documentation reviewed on 30 October 2026.
Define the business result first
Start with one sentence: “When an eligible order is paid, the customer should receive the correct course access and a confirmation.” Replace course access with your own outcome, such as a fulfilment request or CRM update. Name the person responsible when that result does not happen.
Then write down the conditions. Which products qualify? Does a variation change the destination? What should happen to an existing customer? Should a refund remove access or open a manual review? These are business decisions, and the integration needs explicit rules for them.
Use a small acceptance checklist rather than a broad instruction to “connect the apps”. Record the order identifier, the expected destination record and the time within which someone should investigate a missing result. That creates a practical definition of done.
Choose a trigger that matches payment and fulfilment
An order being created is not proof of successful payment. WooCommerce distinguishes Pending payment, Processing, Completed and On hold. Processing generally indicates payment received and fulfilment pending; Completed indicates fulfilment finished. See the official order status reference.
For example, a physical product workflow that waits for Completed before notifying the warehouse may be waiting for an action the warehouse itself is supposed to enable. Equally, granting paid access immediately after order creation can be too early. Agree the correct event and payment conditions for your gateway and products before implementation.
A webhook is a notification sent from the store to another address when a selected event occurs. WooCommerce’s webhook guide explains the available settings under WooCommerce → Settings → Advanced → Webhooks. Some integrations use a plugin or a different event mechanism, so confirm how yours actually starts.
Follow one order through the entire chain
A connection test only proves part of the workflow. WooCommerce sends a ping when a webhook is first saved as Active; that does not demonstrate that a real product maps to the correct external service. Test a representative order and inspect the destination yourself.
| Checkpoint | Evidence to keep |
|---|---|
| Store accepts the eligible order | Order ID, products and payment state |
| Notification reaches the integration | Delivery time and response |
| Integration performs the action | Destination record ID and processing result |
| Customer can use the result | Access, fulfilment state or confirmation checked |
Do not equate an HTTP success response with a completed business action. A receiver may accept work into a queue and fail later. Your acceptance test should check both receipt and the final result, including what the customer sees.
Test failure, repetition and recovery
Use staging with test payment credentials, controlled recipients and a sandbox destination where available. Keep it separate from live fulfilment and customer messaging. If a service has no sandbox, agree a contained test procedure with its owner before sending data.
- Normal purchase: each eligible product produces the intended result.
- Unpaid or failed purchase: no paid benefit is granted prematurely.
- Existing customer: the correct account is updated without creating an unnecessary duplicate.
- Repeated notification: the same business action does not create duplicate access or fulfilment requests.
- Temporary outage: the failure is visible, and an approved recovery restores the missing result.
- Cancellation or refund: the agreed policy is applied or routed for review.
Ask the developer to make repetition safe. A useful design is to track completion using a stable business key, such as the store, order, line item and intended action. An order ID alone may be insufficient when an order contains several courses or partial fulfilments. This is a design recommendation, not a feature every connector provides automatically.
Know where to look when a workflow stops
For native webhooks, review WooCommerce → Status → Logs and filter for webhooks-delivery. Check the webhook’s status too: repeated failed deliveries can disable it. The official troubleshooting instructions cover both. Fix the receiving problem before reactivating delivery, then account for orders missed during the interruption.
If the integration uses Action Scheduler, inspect WooCommerce → Status → Scheduled Actions. Its administration documentation explains how to find failed actions and inspect their logs. Not every external automation appears there; also check the connector and destination service.
Do not rerun a whole queue blindly. First identify which orders are missing which actions, verify whether any already succeeded, and replay only the required work through a process designed to avoid duplicates.
Protect the connection and customer information
Use HTTPS and have the receiving service verify the webhook signature. WooCommerce documents its signature header and shared-secret mechanism in the webhooks API reference. A secret entered in settings is useful only when the receiver checks it correctly.
Keep credentials out of public code and screenshots. Limit customer information in diagnostic exports, restrict log access and decide how long records are retained. When asking for support, share the order identifier, timestamps and relevant error first, rather than an unrestricted dump of customer data.
Create a handover someone can actually use
Before launch, document the trigger, qualifying products, destination, success evidence, failure alert and recovery owner. Agree how frequently paid orders will be compared against completed destination actions. That reconciliation can reveal missed work even when no obvious error reaches the store dashboard.
Recheck the workflow after changes to product mappings, payment gateways, credentials or connected services. Combine these checks with the checkout testing checklist so payment and delivery are tested together. For help planning or repairing a connection, explore development and integration services or tell me what your store needs to do.