Test WooCommerce checkout as a complete order: the selected item, payment provider record, shop order, stock movement, received messages and fulfilment instructions must agree. Use staging and the provider’s supported test mode. A successful-looking thank-you page alone is not a reason to open sales.
A Formby shop offering delivery and collection needs to rehearse both routes with the people who will run them. Choose representative baskets, write the expected outcomes and retain the evidence. This acceptance step follows the catalogue work in our small-shop WooCommerce launch plan.
Make the test environment safe to use
Use a controlled staging copy and list its connections before placing an order. Payment services, email tools, accounting, stock systems, fulfilment services and automation can each respond to an order. A cloned site is not automatically isolated from them.
Confirm that payment is using the provider’s test credentials or sandbox, messages go to agreed test recipients and any external service is in its supported test environment or otherwise isolated. Do not use genuine customer identities or copy payment details into the test record.
WooCommerce’s test-order guidance warns that orders can trigger emails and integrations and recommends staging. Agree how test records will be identified and cleaned up. A normal-looking test order must not reach a packing queue.
Our staging guide covers the wider change process. The developer should settle the environment controls before staff start the rehearsal.
Choose baskets that challenge the rules
| Test case | What to prove |
|---|---|
| Simple product, accepted delivery address | Correct item, total, payment result and delivery instruction |
| Specific size/colour variation | The selected option and SKU persist into the order and picking record |
| Out-of-stock or nonexistent option | No misleading purchasable combination |
| Collection order | Right location and ready/wait instructions before and after checkout |
| Out-of-area or boundary address | The shop follows its real delivery policy |
| Failed payment and retry | Customer sees a useful next step; staff do not treat an unpaid order as paid |
| Cancellation/refund scenario | Payment, order and stock handling follow the agreed process |
Add a mixed basket, discount or special product only when the shop offers it. Testing unused features expands the checklist without protecting your actual business. Our shipping and collection guide supplies the address-rule checks; this rehearsal carries the result through payment and fulfilment.
Start on a phone without administrator login
Find the item through the same category or search route a customer would use. Select its options, inspect the displayed price and availability, add it to the basket and change quantity where appropriate. Confirm that the basket describes the exact item being ordered.
Check whether the screen keyboard hides errors or the next action. Read validation messages with an intentionally incomplete field, then correct it. Confirm that the delivery choice and total are understandable before payment.
Test the shop’s normal consent choices. A buyer declining optional tracking should still be able to use the intended essential purchase route. Record the observed behaviour and have the developer investigate a blocked checkout; do not indiscriminately weaken privacy settings to make the test pass.
Repeat the important path on desktop and at least another browser/device combination available to the business. Name the devices actually checked. Do not call a test comprehensive merely because the responsive preview looked narrow.
Use the payment provider’s test instructions
Test facilities differ by gateway. A bank-transfer or cash-on-delivery order can inspect some shop functions, but it does not prove that the card gateway accepts payment and sends the expected confirmation.
For WooPayments, follow its current test-mode documentation, using its supplied test methods. The page explains how to inspect the corresponding order and transaction and warns that real live payments followed by refunds can leave transaction fees. Use the equivalent official instructions for another provider.
Include a supported failed-payment scenario and a retry where relevant. Keep timestamps and non-sensitive order/transaction identifiers so the developer can join the evidence. Do not record card numbers, security codes or credentials in the test sheet.
Join the evidence across the order
For each case, inspect the shop order and gateway result. Verify the selected variation, quantity, agreed price/tax display, shipping or pickup choice and total. Read the order notes when something differs; do not fix a payment mismatch by manually marking the order paid.
WooCommerce’s order-status reference explains Pending payment, Processing, Completed and the other states. Configure the business process around what each state means. A physical item awaiting packing is not the same event as an order already fulfilled.
Inspect stock before and after the test, including the correct variation. For cancellations and refunds, record whether stock should be returned and check the actual action. A shop with shared counter stock also needs to rehearse an in-person sale or correction through its agreed stock-update route.
If option identifiers are unclear, revisit the variation stock plan. If changed catalogue values are wrong, inspect the CSV import reconciliation rather than applying unexplained manual corrections to the sample.
Check received messages and the packing handoff
Read messages at both receiving ends. Confirm the customer can identify what was ordered, what happens next and how to ask for help. Check the staff destination and whether reply handling works. A template preview or queued email is not evidence of receipt.
For collection, the person serving the customer must know whether the order is paid and ready. For dispatch, ask the packer to identify the exact item and produce the intended paperwork from the test record. If a label printer is part of the workflow, test its actual output and fit before buying another machine.
Use this copyable record: test name; environment/version; date and device; basket/options; address type; expected result; order and gateway reference; stock before/after; received messages; fulfilment outcome; exception; owner; retest result. Keep sensitive customer data and credentials out.
Retest changes and keep staging orders off live
Fix one understood cause at a time, then rerun the failed case and the ordinary successful path. If the change affects shipping, totals, payments or stock, retest its adjacent cases too. Retain the failed result and the successful retest so the reason for sign-off is inspectable.
Do not deploy a staging database containing test orders over the live trading database. Agree which code/configuration changes move and how live orders, stock and customer records are preserved. This belongs in the shop hosting and recovery plan.
Before launch, check that the public configuration uses the approved live payment environment and real business message destinations, with temporary test content removed. A staging rehearsal does not verify the live provider connection; the owner and developer must complete the provider’s live activation checks through an authorised process.
Stop release if the shop cannot reliably distinguish a paid order, select the right stock item or honour the shown fulfilment choice. Once accepted, give staff the record and the escalation contact, then use the handover checklist to record operational responsibility.
