# Launch a WooCommerce store

Prepare a physical-goods WooCommerce store from catalog and fulfillment rules through sandbox orders, safe cutover and first-order operations.

Canonical: https://xcloud.host/use-cases/playbooks/launch-a-woocommerce-store/
Published: 2026-09-30 · Updated: 2026-09-30 · Technical review: 2026-09-30
Evidence: Source reviewed; no production deployment test claimed
Editorial owner: xCloud editorial

Intent: Prepare a physical-goods WooCommerce store for launch and verify its buyer, staff and recovery paths.
For: business-owner, store-operator

## Requirements and responsibilities

- Name the store owner, WordPress administrator, domain/DNS owner, payment-provider owner, tax adviser and fulfillment lead. Agree sellable region, currency, product types, return policy and who answers a failed payment. A hosting site does not choose those business rules. Sources: [WooCommerce online store setup](https://woocommerce.com/document/build-online-store/); [WordPress roles and capabilities](https://wordpress.org/documentation/article/roles-and-capabilities/)
- Use a native WordPress site on a compatible xCloud Nginx or OpenLiteSpeed server. Check the selected WooCommerce and gateway versions, licenses and provider account before installation; do not imply that xCloud hosting configures the store. Sources: [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md); [WooCommerce online store setup](https://woocommerce.com/document/build-online-store/); [WordPress plugin administration](https://wordpress.org/documentation/article/manage-plugins/)
- Before copying production data to a test site or restoring a backup, restrict the target and quarantine outbound payment, email, fulfillment and inventory effects. Copied settings can overwrite suppression; reapply sandbox credentials and verify isolation before any order test. Sources: [Create a staging environment in xCloud](https://xcloud.host/docs/how-to-create-a-staging-environment-in-xcloud/); [WooCommerce testing orders](https://woocommerce.com/document/managing-orders/testing-orders/); [Site backups in xCloud](https://xcloud.host/docs/site-backups-in-xcloud/)

## Illustrative situation

Illustrative scenario: a small retailer will sell stocked products with local pickup and one shipping region. The owner has product data and customer-support staff, but needs to decide stock, tax, payment, fulfillment and recovery before sending traffic to the store.

## Choose the approach

- Use WooCommerce core settings for catalog, stock, shipping zones, tax calculation and order emails only where they meet the approved requirement. A payment gateway, automated tax product or shipping extension is a separate provider choice with its own documentation and license. Sources: [WooCommerce online store setup](https://woocommerce.com/document/build-online-store/); [WooCommerce product and inventory settings](https://woocommerce.com/document/configuring-woocommerce-settings/products/); [WooCommerce shipping zones](https://woocommerce.com/document/setting-up-shipping-zones/); [WooCommerce tax settings](https://woocommerce.com/document/setting-up-taxes-in-woocommerce/)
- Place marked test orders on an isolated staging store with the gateway sandbox. WooCommerce warns that test orders may trigger emails and other integrations, so reconcile test events before turning live traffic on. Sources: [WooCommerce testing orders](https://woocommerce.com/document/managing-orders/testing-orders/); [Create a staging environment in xCloud](https://xcloud.host/docs/how-to-create-a-staging-environment-in-xcloud/)

## Dashboard and application procedure

### 1. Approve the commercial contract

**Where:** Store-owner launch worksheet

**Permissions:** Business owner, finance/tax adviser and fulfillment lead approve their own rules.

**Inputs:** Product types, sellable region, currency, return promise, shipment and support owners.

**Action:** Write one order contract for a representative stocked item: price and currency, SKU, sellable region, tax decision, shipping or pickup method, return rule and staff response to a failed payment. Have the responsible owners sign it before building checkout.

**Expected result:** A single marked order can be evaluated against approved commercial rules.

**Verify:** Ask finance and fulfillment to recalculate the sample total and describe how the order would be shipped or collected.

**If it fails:** If tax jurisdiction, shipping reach or refund ownership is unresolved, do not open paid checkout; retain the store in private preparation.

Capability: Business owner review and acceptance
Sources: [WooCommerce online store setup](https://woocommerce.com/document/build-online-store/); [WooCommerce tax settings](https://woocommerce.com/document/setting-up-taxes-in-woocommerce/)

### 2. Provision native WordPress

**Where:** xCloud Add Site dashboard

**Permissions:** Named xCloud team and site administrator provisions the approved native WordPress site.

**Inputs:** Approved team, compatible server, domain, WordPress admin identity and current stack requirements.

**Action:** Create the native WordPress site under the approved xCloud team and compatible Nginx or OpenLiteSpeed server. Confirm returned site and server identity and keep public DNS on its previous destination until the store’s acceptance and recovery checks pass.

**Expected result:** The intended hostname and team have a reachable WordPress administrator without public cutover.

**Verify:** Compare the returned xCloud team, site, server and dashboard URL with the signed launch worksheet before opening application setup.

**If it fails:** If the stack or hostname is wrong, correct the target before installing commerce plugins; do not create a duplicate public site.

Capability: Create a WordPress site
Sources: [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md); [xCloud MCP documentation and connection profiles](https://app.xcloud.host/mcp/docs)

### 3. Install and identify WooCommerce

**Where:** WordPress Plugins and WooCommerce setup checklist

**Permissions:** Named WordPress administrator installs the plugin; store owner approves shop address and currency.

**Inputs:** Approved WordPress site, current WooCommerce release, plugin requirements, store address, currency and operator account.

**Action:** In the approved WordPress administrator install the selected supported WooCommerce release and follow its store setup checklist. Confirm the address and currency against the merchant worksheet; record the exact plugin version and license or integration dependencies before entering products.

**Expected result:** WooCommerce runs on the correct WordPress site with the merchant-approved base identity.

**Verify:** Sign in as the store operator and compare plugin version, shop address and currency with the launch worksheet.

**If it fails:** If the plugin or currency is wrong, leave checkout private and resolve application settings before catalog or payment work.

Capability: Configure WordPress content, users and selected plugins
Sources: [WooCommerce online store setup](https://woocommerce.com/document/build-online-store/); [WordPress plugin administration](https://wordpress.org/documentation/article/manage-plugins/); [WordPress roles and capabilities](https://wordpress.org/documentation/article/roles-and-capabilities/)

### 4. Build the sellable catalog and stock policy

**Where:** WooCommerce Products and inventory settings

**Permissions:** Named store manager or WordPress/WooCommerce administrator.

**Inputs:** Approved SKUs, images and rights, prices, stock quantities, backorder decision and customer-facing policies.

**Action:** Enter one simple product and one representative variation where needed. Set SKU, price, images, stock tracking and backorder rule, then publish shipping, returns and contact pages with owner-approved wording. Check that the public product displays only options the warehouse can fulfill.

**Expected result:** A buyer sees accurate stock and policy information, and staff can find the same SKU in the inventory screen.

**Verify:** As a signed-out buyer choose each sample option; ask the stock owner to compare displayed availability with the source inventory ledger.

**If it fails:** If a product can be bought while the source ledger says unavailable, pause that SKU and reconcile stock settings before launch.

Capability: Configure WordPress content, users and selected plugins
Sources: [WooCommerce product and inventory settings](https://woocommerce.com/document/configuring-woocommerce-settings/products/); [WooCommerce online store setup](https://woocommerce.com/document/build-online-store/); [WordPress roles and capabilities](https://wordpress.org/documentation/article/roles-and-capabilities/)

### 5. Configure shipping, tax, payment and email

**Where:** WooCommerce Settings and selected gateway account

**Permissions:** WooCommerce administrator changes store settings; finance approves tax; gateway owner controls sandbox credentials.

**Inputs:** Approved tax decision, shipping/pickup zones, rate table, gateway sandbox and staff/customer mail recipients.

**Action:** Configure only the approved shipping zones and methods, then enter tax settings according to the adviser’s decision rather than guessing rates. Connect the selected gateway in its test environment and set new-order, failed-order and customer mail recipients in WooCommerce.

**Expected result:** The sample address receives the intended shipping choice, calculated total and notification destinations in the isolated store.

**Verify:** Recalculate subtotal, tax, shipping and discount for one address inside and one outside the sellable region; compare mailbox and gateway settings.

**If it fails:** If an address receives an unsupported method or a tax total disagrees with the approved example, hold the sales launch and correct that rule.

Capability: Configure WordPress content, users and selected plugins
Sources: [WooCommerce shipping zones](https://woocommerce.com/document/setting-up-shipping-zones/); [WooCommerce tax settings](https://woocommerce.com/document/setting-up-taxes-in-woocommerce/); [WooCommerce email notification settings](https://woocommerce.com/document/configuring-woocommerce-settings/emails/); [WooCommerce testing orders](https://woocommerce.com/document/managing-orders/testing-orders/)

### 6. Record a completed recovery point

**Where:** xCloud Site Backup dashboard

**Permissions:** Named xCloud site administrator and store data owner.

**Inputs:** Backup destination, files/database scope, retention, target for safe rehearsal and current store-data timestamp.

**Action:** In Site Backup inspect the configured native WordPress schedule and destination, then confirm a completed files-and-database point before the launch window. Record its identifier and check that uploads, catalog settings and orders are included; plan a separate restricted restore rehearsal.

**Expected result:** The team has an accessible pre-launch point and knows its data-loss window.

**Verify:** Record backup identifier, completion time and destination access, then compare that time with the latest sample order.

**If it fails:** If the job is pending, failed or missing database scope, keep cutover blocked until a completed point and restore owner exist.

Capability: Configure native WordPress backup and restore
Sources: [Site backups in xCloud](https://xcloud.host/docs/site-backups-in-xcloud/); [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md)

### 7. Test buyer and staff order outcomes

**Where:** Isolated WooCommerce staging and gateway sandbox

**Permissions:** Store manager and payment-provider test-account owner; no live customer credentials.

**Inputs:** Marked test buyer, two shipping addresses, coupon, sandbox success/decline methods, staff mailbox and stock baseline.

**Action:** Place a successful sandbox order and a declined payment, with the agreed coupon and shipping address cases. Inspect order status, provider event, tax and shipping total, stock movement, customer email and staff notice; keep fulfillment hooks quarantined during the test.

**Expected result:** Only the successful test advances to the expected fulfillable state; rejected payment and unsupported shipping do not create a false sale.

**Verify:** Compare WooCommerce order IDs with provider sandbox events and the stock ledger; have fulfillment staff identify which marked order they would process.

**If it fails:** If order, provider, stock or mail disagree, stop launch, preserve the test evidence and repair the responsible integration before retesting.

Capability: Configure and test application behavior
Sources: [WooCommerce testing orders](https://woocommerce.com/document/managing-orders/testing-orders/); [WooCommerce product and inventory settings](https://woocommerce.com/document/configuring-woocommerce-settings/products/); [WooCommerce email notification settings](https://woocommerce.com/document/configuring-woocommerce-settings/emails/)

### 8. Approve DNS and HTTPS cutover

**Where:** Domain DNS provider, xCloud SSL view and public browser

**Permissions:** Domain owner changes DNS; xCloud site owner verifies certificate; store owner signs routing.

**Inputs:** Approved hostname, record values, old-site fallback, certificate and timing after isolated order acceptance.

**Action:** After the owner signs the sandbox order and recovery sheet, keep public checkout gated while the domain owner updates exact approved records and the xCloud owner verifies HTTPS. From an independent browser confirm canonical host, product, cart and checkout routing; retain old routing evidence until late data are reconciled.

**Expected result:** Visitors reach the intended secure product pages, while paid checkout remains gated pending live-provider readiness.

**Verify:** Compare authoritative DNS with the approved record and repeat product, cart, login and contact checks from a fresh session.

**If it fails:** If DNS or certificate is inconsistent, keep the previous destination and involve the DNS/SSL owners before accepting new sales.

Capability: Change domain DNS and verify routing
Sources: [Enable HTTPS and configure SSL certificates in xCloud](https://xcloud.host/docs/enable-https-in-xcloud-configure-ssl-certificates/); [xCloud WordPress migration guide](https://xcloud.host/docs/guide-to-wordpress-site-migration-on-xcloud/)

### 9. Activate the approved live payment path

**Where:** Production WooCommerce payment settings and selected provider account

**Permissions:** Named merchant payment owner controls live account and credentials; store owner approves opening sales.

**Inputs:** Production domain, selected provider’s live onboarding instructions, merchant identity, webhook/callback destination and checkout gate.

**Action:** On the production site only, have the payment owner activate the approved live merchant account or credentials according to that provider’s instructions. For WooPayments, distinguish test account from live activation. Verify merchant identity, live callback destination and actual mode without copying staging keys or switching the staging gateway to live; use only the provider’s approved production-safe check before opening paid checkout.

**Expected result:** The correct production merchant path is ready and the owner explicitly opens sales only after mode and callback checks pass.

**Verify:** Have the payment owner show the live account status, production domain and provider-approved verification result, then record the checkout-opening decision.

**If it fails:** If the gateway remains in test mode, the live account is incomplete or callbacks point at staging, keep checkout gated and contact the provider.

Capability: Configure WordPress content, users and selected plugins
Sources: [WooPayments test-to-live account transition](https://woocommerce.com/document/woopayments/testing-and-troubleshooting/test-accounts/); [WooCommerce testing orders](https://woocommerce.com/document/managing-orders/testing-orders/); [WooCommerce online store setup](https://woocommerce.com/document/build-online-store/)

### 10. Hand off first orders and recovery decisions

**Where:** WooCommerce orders, payment provider and store operations ledger

**Permissions:** Store manager, fulfillment lead and owner of any backup restore.

**Inputs:** First live order IDs, provider settlement state, support mailbox, stock owner and backup timestamp.

**Action:** During the first trading window, reconcile real order IDs with payment events, stock decrements and shipping or pickup work. Name who checks failed orders and mail each day; before any database restore compare newer paid orders with the selected point and decide how they will be preserved or replayed.

**Expected result:** Staff can fulfill every paid order and an owner can explain the recovery decision without losing later transactions.

**Verify:** Ask fulfillment to trace one real order from payment to item handoff and identify all orders created after the recorded backup point.

**If it fails:** If a paid order is missing or payment state is unclear, keep an incident open and reconcile with the provider before changing the database.

Capability: Configure and test application behavior
Sources: [WooCommerce testing orders](https://woocommerce.com/document/managing-orders/testing-orders/); [Site backups in xCloud](https://xcloud.host/docs/site-backups-in-xcloud/); [WooCommerce email notification settings](https://woocommerce.com/document/configuring-woocommerce-settings/emails/)

## Maintenance

- After release, the store manager reviews failed and paid order states, stock exceptions, customer mail and fulfillment each trading day. Schedule selected WordPress, WooCommerce and extension updates outside critical sales windows and retest a marked order after changes. Sources: [WooCommerce testing orders](https://woocommerce.com/document/managing-orders/testing-orders/); [Manage WordPress updates with Updates Manager](https://xcloud.host/docs/manage-wordpress-updates-with-updates-manager/); [WooCommerce product and inventory settings](https://woocommerce.com/document/configuring-woocommerce-settings/products/)
- Inspect actual backup completion and storage access, not only a configured schedule. Rehearse an isolated recovery at a suitable cadence with outbound providers quarantined. Sources: [Site backups in xCloud](https://xcloud.host/docs/site-backups-in-xcloud/); [Create a staging environment in xCloud](https://xcloud.host/docs/how-to-create-a-staging-environment-in-xcloud/)

## Recovery decisions

- If checkout fails, preserve live order and payment evidence before deciding between a forward fix and a restore. A previous database point can omit newer paid orders; reconcile those records and stock with the provider before any in-place recovery. Sources: [Site backups in xCloud](https://xcloud.host/docs/site-backups-in-xcloud/); [WooCommerce testing orders](https://woocommerce.com/document/managing-orders/testing-orders/)
- A test copy must have mail, gateway and fulfillment effects blocked before a restored database starts. Reapply sandbox credentials after copying settings and prove isolation before placing another test order. Sources: [Create a staging environment in xCloud](https://xcloud.host/docs/how-to-create-a-staging-environment-in-xcloud/); [WooCommerce testing orders](https://woocommerce.com/document/managing-orders/testing-orders/)

## AI handoff

Connect xCloud MCP for the named team and discover the granted tools, schemas and scopes. Use resource reads to confirm site identity and returned dashboard URLs. The packaged REST fallback is GET-only; staging, backup schedules, restores and cache settings require the dashboard, while WooCommerce, booking and WordPress content settings belong to their named application owners.

### Supported scope

- **Confirm requirements and inspect resources** (mcp; read): Discover the connected profile and operation schema first; only teams granted to the connection are visible. Checkpoint: Confirm exact team, server and site identity. Use dashboard\_url returned by the resource; do not invent a dashboard link. Operation identifiers to discover: teams.index, servers.show, sites.show. Scopes: read:servers, read:sites. Sources: [xCloud MCP documentation and connection profiles](https://app.xcloud.host/mcp/docs); [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md)
- **Business owner review and acceptance** (app; manual): Human planning, acceptance and record reconciliation cannot be inferred from xCloud resource reads. The business owner chooses the application's source of truth. Checkpoint: Record approved criteria, observed application evidence, unresolved questions and named follow-up. Sources: [WordPress roles and capabilities](https://wordpress.org/documentation/article/roles-and-capabilities/); [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md)
- **Create a WordPress site** (mcp; write): Requires a compatible Nginx or OpenLiteSpeed server; Docker and single-site agentic servers cannot host a new WordPress site. Checkpoint: Approve the exact server, domain, capacity, cost and creation inputs before provisioning. Verify completion and HTTPS. Operation identifiers to discover: servers.sites.wordpress.create. Scopes: write:sites. Sources: [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md); [xCloud MCP documentation and connection profiles](https://app.xcloud.host/mcp/docs)
- **Configure WordPress content, users and selected plugins** (app; manual): Requires a named WordPress administrator or suitable editor. Plugin behavior, commercial license, payment, email and external integration are verified in the chosen vendor documentation and application; xCloud hosting or MCP reads do not configure them. Checkpoint: Open the actual WordPress or selected plugin interface, record the version and role, and have the business owner accept a real user journey. Sources: [WordPress roles and capabilities](https://wordpress.org/documentation/article/roles-and-capabilities/); [WordPress plugin administration](https://wordpress.org/documentation/article/manage-plugins/)
- **Configure native WordPress backup and restore** (dashboard; manual): Native schedule, retention and destination changes and all restores are dashboard-only. Checkpoint: Use Site → Site Backup. Before restoring, confirm backup, target, scope and treatment of newer records. Sources: [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md)
- **Configure and test application behavior** (app; manual): xCloud hosting operations do not configure WooCommerce checkout, n8n workflows, Nextcloud sharing policy or application users. Checkpoint: An application administrator verifies each real business journey and records observed outcomes. Sources: [WooCommerce testing orders](https://woocommerce.com/document/managing-orders/testing-orders/); [n8n Webhook node and test/production URLs](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.webhook/); [Nextcloud file sharing administration](https://docs.nextcloud.com/server/stable/admin_manual/configuration_files/file_sharing_configuration.html); [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md)
- **Change domain DNS and verify routing** (app; manual): DNS changes belong to the domain provider or authorized DNS integration; reading an xCloud site does not establish public propagation or certificate validity. Checkpoint: Approve exact hostname and record values; check authoritative DNS and live HTTPS from an independent session. Sources: [xCloud WordPress migration guide](https://xcloud.host/docs/guide-to-wordpress-site-migration-on-xcloud/); [Enable HTTPS and configure SSL certificates in xCloud](https://xcloud.host/docs/enable-https-in-xcloud-configure-ssl-certificates/)

### Copyable agent brief

```text
For the exact store team and site I name, inspect hosting identity, stack and completed backup status through granted xCloud reads. Prepare the store launch worksheet for catalog, stock, shipping, tax adviser, gateway sandbox, mail and DNS owners. Keep checkout gated through DNS cutover until the named payment owner verifies the production merchant account, live mode and callbacks by provider instructions. Do not claim a payment, order, backup restore or DNS change happened from MCP reads. The packaged REST fallback is GET-only. Return a cutover decision with exact blockers and a newer-order recovery plan.
```

### Manual checkpoints

- A WooCommerce administrator configures catalog, stock, shipping, tax settings, gateway and mail with the named finance/payment owners.
- The xCloud site owner verifies backup completion; an isolated staging operator quarantines outbound effects before sandbox orders.
- The domain owner performs approved DNS changes; the payment owner verifies production live mode and callbacks before the store owner opens sales.
- The store owner accepts real order, payment, stock and fulfillment evidence.

## Feature coverage

- **store-and-catalog-setup** (covered): Separates hosting provision, WooCommerce installation, products, inventory and policies. Steps: scope, provision, woo-setup, catalog
- **commercial-settings** (covered): Names tax, shipping, gateway, notification and production-payment owners with address examples. Steps: rules, payment-live
- **sandbox-order-acceptance** (covered): Checks successful and declined orders, totals, stock and mail on isolated staging. Steps: orders
- **launch-and-recovery** (covered): Requires completed backup, gated DNS/HTTPS cutover, live payment readiness and preservation of post-backup orders. Steps: backup, cutover, payment-live, operate

## Sources

- [WooCommerce online store setup](https://woocommerce.com/document/build-online-store/) — reviewed 2026-09-30
- [WordPress roles and capabilities](https://wordpress.org/documentation/article/roles-and-capabilities/) — reviewed 2026-09-30
- [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md) — reviewed 2026-09-30; v4.4.2 package; xCloud v2.8.8 capability review
- [WordPress plugin administration](https://wordpress.org/documentation/article/manage-plugins/) — reviewed 2026-09-30
- [Create a staging environment in xCloud](https://xcloud.host/docs/how-to-create-a-staging-environment-in-xcloud/) — reviewed 2026-09-30
- [WooCommerce testing orders](https://woocommerce.com/document/managing-orders/testing-orders/) — reviewed 2026-09-30
- [Site backups in xCloud](https://xcloud.host/docs/site-backups-in-xcloud/) — reviewed 2026-09-30
- [WooCommerce product and inventory settings](https://woocommerce.com/document/configuring-woocommerce-settings/products/) — reviewed 2026-09-30
- [WooCommerce shipping zones](https://woocommerce.com/document/setting-up-shipping-zones/) — reviewed 2026-09-30
- [WooCommerce tax settings](https://woocommerce.com/document/setting-up-taxes-in-woocommerce/) — reviewed 2026-09-30
- [Manage WordPress updates with Updates Manager](https://xcloud.host/docs/manage-wordpress-updates-with-updates-manager/) — reviewed 2026-09-30
- [xCloud MCP documentation and connection profiles](https://app.xcloud.host/mcp/docs) — reviewed 2026-09-30
- [WooCommerce email notification settings](https://woocommerce.com/document/configuring-woocommerce-settings/emails/) — reviewed 2026-09-30
- [Enable HTTPS and configure SSL certificates in xCloud](https://xcloud.host/docs/enable-https-in-xcloud-configure-ssl-certificates/) — reviewed 2026-09-30
- [xCloud WordPress migration guide](https://xcloud.host/docs/guide-to-wordpress-site-migration-on-xcloud/) — reviewed 2026-09-30
- [WooPayments test-to-live account transition](https://woocommerce.com/document/woopayments/testing-and-troubleshooting/test-accounts/) — reviewed 2026-09-30
- [n8n Webhook node and test/production URLs](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.webhook/) — reviewed 2026-09-30
- [Nextcloud file sharing administration](https://docs.nextcloud.com/server/stable/admin_manual/configuration_files/file_sharing_configuration.html) — reviewed 2026-09-30

## Continue

[Verify WooCommerce checkout](https://xcloud.host/use-cases/solutions/woocommerce-checkout-launch-readiness/)

- [Check WooCommerce checkout before launch](https://xcloud.host/use-cases/solutions/woocommerce-checkout-launch-readiness/)
- [Accept WooCommerce orders after a release](https://xcloud.host/use-cases/solutions/accept-woocommerce-orders-after-a-release/)
- [Plan WooCommerce backup coverage](https://xcloud.host/use-cases/solutions/plan-woocommerce-backup-coverage/)