Commerce Workflow

Use this runbook when a workspace sells products through a Sophosic site.

Outcome

At the end:

Step 1: Connect Payments

Console surfaces: Payments, Settings > Checkout and Tax.

Actions:

1. Open Payments.
2. Connect or resume Stripe Connect onboarding.
3. Review requirements, payouts, currency, and business profile.
4. Open Settings > Checkout and Tax.
5. Configure checkout availability, tax posture, invoice behavior, and manual-payment policy.

Verify:

• Payment account status is healthy enough for the launch path.
• Financial owner understands payout timing and fees.
• Checkout is not publicly exposed before payment readiness.

Failure checks:

• Missing Stripe requirements can block checkout.
• Wallets can require separate payment method domain verification.
• Tax or shipping settings can make totals look wrong even when Stripe works.

Step 2: Create Products

Console surface: Products.

For each product, configure:

• Title.
• Description.
• Media.
• Price.
• Tax classification.
• Variants.
• Modifiers.
• Inventory.
• Collections.
• SEO fields.
• Shipping details.
• Publish state.

Verify on sites:

• Product appears in /shop.
• Product detail route loads.
• Images and options display correctly.
• Unavailable variants cannot be purchased.
• Archived products are not visible.

Step 3: Configure Collections And Navigation

Console surfaces: Products, Website.

Actions:

1. Add collections for customer browsing.
2. Attach products to collections.
3. Link shop or collection pages from navigation.
4. Add product-grid blocks to relevant pages if needed.

Verify:

• Customers can discover products from the homepage or navigation.
• Filters do not hide every product.
• Empty collection states are acceptable.

Step 4: Configure Inventory

Console surface: Products > Inventory.

Actions:

• Set stock counts or availability.
• Confirm backorder policy if any.
• Verify low-stock and out-of-stock behavior.
• Check inventory after a completed checkout.

Verify on sites:

• Out-of-stock products cannot be oversold unless the business intends it.
• Cart and checkout revalidate inventory.

Step 5: Configure Shipping

Console surfaces: Shipping, Products > Shipping.

Actions:

1. Set ship-from origin.
2. Create package presets.
3. Configure zones.
4. Configure rates.
5. Add product dimensions and weights.
6. Connect shipping provider if labels are bought through the console.

Verify on sites:

• Checkout displays valid shipping options.
• Totals update when shipping address changes.
• Pickup or no-shipping products behave intentionally.

Failure checks:

• Missing dimensions can block rates.
• Origin or destination mismatch can block labels.
• Some carriers do not support every package mode.

Step 6: Run Checkout

Sites surfaces:

• /shop.
• /shop/{productSlug}.
• /cart.
• /checkout.
• /checkout/success.
• /checkout/return.
• /checkout/cancel.

Test:

1. Add a product to cart.
2. Change quantity.
3. Select options or modifiers.
4. Enter contact and shipping details.
5. Apply coupon if used.
6. Confirm tax and shipping.
7. Complete payment.
8. Land on success.

Verify in console:

• Order appears in Sales or Orders.
• Payment status is correct.
• Customer record is created or linked.
• Inventory changed as expected.
• Notification was sent.

Step 7: Fulfill The Order

Console surfaces: Sales, Orders, Shipping.

Actions:

1. Open order detail.
2. Review payment and fulfillment state.
3. Confirm shipping address.
4. Buy label if enabled.
5. Add tracking.
6. Mark fulfillment progress.
7. Record notes if needed.

Verify on sites:

• Customer order history shows the order.
• Tracking page or order detail shows fulfillment progress.
• Email notifications match the status.

Step 8: Test Refunds And Cancellations

Console surfaces: Orders, Payments.

Actions:

• Cancel unpaid order.
• Refund paid order.
• Record out-of-band refund when appropriate.
• Confirm inventory behavior.
• Confirm customer notification.

Verify:

• Console order state changes.
• Payment or refund state is visible.
• Inventory impact matches the business rule.
• Customer notification is sent only when appropriate.
• Customer portal order history remains understandable.

Refund and cancellation testing should identify who can approve money movement, what customer message is sent, and what record proves the action occurred.

• Stripe state, console order state, and customer portal state agree.
• Refund amount and reason are clear.

Step 9: Verify Customer Portal

Sites surfaces:

• /account.
• /orders.
• /orders/{orderId}.
• /account/saved.
• /profile/notifications.

Test:

• Customer can sign in.
• Order appears.
• Order totals, items, fulfillment state, refunds, and tracking links match console.
• Guest checkout can be claimed only when the workflow supports it.

Use a customer account with realistic history if possible. Empty portal checks prove authentication, but they do not prove order ownership, billing visibility, saved items, or customer-facing status language.

• Order detail is scoped to that customer.
• Saved items and reorder paths work if enabled.
• Notification preferences are respected.

Commerce Done Criteria

Use these criteria before turning on ads, promotions, or homepage merchandising that points to shop pages. Commerce is ready when the team can sell, fulfill, support, refund, and explain an order from both the customer view and the console view.

• Product can be found.
• Product can be bought.
• Order appears in console.
• Payment is recorded.
• Fulfillment path is clear.
• Customer can see the order.
• Refund/cancel path is known.
• Notifications are correct.