Launch a WooCommerce store

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.

Sources: WooCommerce online store setup · WooCommerce tax settings

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.

Sources: xCloud agent capability boundaries · xCloud MCP documentation and connection profiles

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.

Sources: WooCommerce online store setup · WordPress plugin administration · WordPress roles and capabilities

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.

Sources: WooCommerce product and inventory settings · WooCommerce online store setup · WordPress roles and capabilities

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.

Sources: WooCommerce shipping zones · WooCommerce tax settings · WooCommerce email notification settings · WooCommerce testing orders

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.

Sources: Site backups in xCloud · xCloud agent capability boundaries

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.

Sources: WooCommerce testing orders · WooCommerce product and inventory settings · WooCommerce email notification settings

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.

Sources: Enable HTTPS and configure SSL certificates in xCloud · xCloud WordPress migration guide

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.

Sources: WooPayments test-to-live account transition · WooCommerce testing orders · WooCommerce online store setup

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.

Sources: WooCommerce testing orders · Site backups in xCloud · WooCommerce email notification settings