Checkout Architecture
Part of Ecommerce platform integrations
Testing order updates across connected systems
Use a focused test sheet for payment, address, cancellation, fulfilment and refund updates across connected ecommerce systems.
Test an integration by changing an existing order and checking the result in every connected system that uses it. A new order arriving alone does not show what happens after a late payment, correction, partial fulfilment or refund. Write the expected result for each case before you run it.
Prepare a controlled route
Use the proposed platform, connector settings and destination accounts. Where the systems permit it, separate test records from live picking and accounting. Before creating them, confirm how the chosen payment gateway and apps treat test orders, messages and stock.
Change to attempt / Records to inspect
- Payment confirms after order creation
- Commerce payment state, fulfilment release and accounting trigger
- Address changes before dispatch
- Store order, warehouse task and customer message
- One line is cancelled
- Destination lines, stock and financial adjustment
- Part of an order ships
- Fulfilled quantity, remaining quantity and tracking
- Partial refund is issued
- Payment-provider result, commerce record and accounting adjustment
- The same event is delivered twice
- Destination records and actions created
- An older update arrives after a newer one
- Final state in the store and destination
For Shopify webhooks, verify deliveries and ignore duplicates using X-Shopify-Webhook-Id. The acceptance result is the correct current record, not merely receipt of every notification.
Check the destination record
For each case, retain the commerce order ID, event or transfer ID, destination ID, expected result, observed result and defect owner. A successful webhook response may acknowledge delivery while later processing fails. Inspect the warehouse task or accounting entry itself.
Write the fulfilment release condition for the proposed store. BigCommerce describes callback data as a lightweight description of the event; its store/order/created example contains the order type and ID. Treat the event as a change signal, not as the complete order record.
WooCommerce has distinct pending-payment, on-hold and processing states, and payment methods can affect transitions. A generic new-order event is insufficient as a release rule.
Include operator changes
Have an operator make a permitted address or line correction through the normal admin route. Check whether the destination updates the original record.
If a dispatched task or posted financial record cannot be amended, document the permitted adjustment and its owner. A post-dispatch change may require customer service rather than an automatic overwrite.
For refunds, check the payment provider as well as the order state. WooCommerce says a manual refund requires funds to be returned outside WooCommerce. The case must distinguish an accounting adjustment from money returned to the customer.
Mark each case passed, failed or unresolved against its expected result. Keep the failed record after a fix and run the case again.
