Commerce and Bookings

Commerce and bookings share the same goal: let customers commit to work and let operators fulfill it. Products usually move through catalog, cart, checkout, order, shipping, and customer portal. Services usually move through service selection, schedule, intake, payment, confirmation, calendar, and lifecycle.

The two flows can share customers, payments, invoices, notifications, and portal history, but their readiness checks are different. Product flows are inventory and fulfillment sensitive. Booking flows are capacity and calendar sensitive. Treat each as its own launch path even when the same workspace offers both.

Flow Ownership

1. Product sale

   Console owner: Products, Checkout and Tax, Payments, Shipping

   Public proof: Product detail, cart, checkout, order history

2. Shippable order

   Console owner: Products, Shipping, Orders

   Public proof: Address capture, rate/label behavior, tracking

3. Service booking

   Console owner: Scheduling, Services, Availability, Payments

   Public proof: Service detail, scheduler, confirmation, booking history

4. Booking payment

   Console owner: Scheduling, Payments, Checkout behavior

   Public proof: Deposit or final-payment state updates the booking

5. Customer account

   Console owner: Customers, Notifications, Portal settings

   Public proof: Orders, bookings, billing, tickets, saved items are scoped correctly

Products

Use Products to manage:

• Product title, description, media, and SEO.
• Pricing, tax, modifiers, variants, and options.
• Inventory and availability.
• Collections and product organization.
• Shipping dimensions and fulfillment settings.
• Archive and publish state.

Verify on sites:

• Product list and filters.
• Product detail.
• Modifier selection.
• Cart totals.
• Checkout.
• Saved items and reorders.

Orders

Orders are created from product checkout and may include shipping, fulfillment, cancellation, refund, and reorder paths.

Operators should check:

• Payment status.
• Fulfillment status.
• Shipping address.
• Tracking.
• Customer record association.
• Notes and timeline.

Customers should be able to view their order history from the portal.

Order operations should preserve the customer timeline. If staff cancel, refund, fulfill, or add notes, the resulting state should be visible from the order detail and reflected in customer communications when appropriate.

Shipping

Shipping is the logistics surface for product orders. Configure:

• Ship-from origin.
• Package presets.
• Shipping zones.
• Rates.
• Label purchase.
• Tracking and fulfillment states.
• Returns when enabled.

If a label purchase fails, check product dimensions, origin, destination, provider configuration, and whether the selected carrier supports the requested package mode.

Payments

Payments is the Stripe Connect money surface. It supports account connection, payment visibility, customer sync, connected-account requirements, payouts, and operator payment actions.

Paid workflows may use:

• Product checkout.
• Booking deposit checkout.
• Booking final-payment checkout.
• Hosted invoices.
• Embedded payment links.
• Manual payment recording.
• Refunds or credit notes.

See Stripe Connect before enabling payment collection.

Payments should be verified against the exact customer action. A connected account is not enough; a product checkout, booking deposit, final payment, invoice, refund, or manual payment can each have different provider behavior and operator permissions.

Services

Services are bookable offerings. Configure:

• Duration and buffer.
• Staff or resource assignment.
• Location.
• Pricing.
• Tiers.
• Add-ons.
• Waivers.
• Intake forms.
• Deposit amount and payment timing.
• Auto-finalize or manual lifecycle policy.

Verify on sites:

• Service list.
• Service detail.
• Tier selection.
• Scheduler.
• Add-ons.
• Waiver.
• Confirmation.
• Manage and reschedule links.

Availability

Availability is the promise the public scheduler makes to customers. It combines business hours, service rules, staff, overrides, capacity, existing bookings, and connected calendars.

Availability should be tested from the public booking path, not only from the console setup screen. The customer-facing scheduler is the place where duration, buffer, staff/resource assignment, external calendar conflicts, booking limits, deposits, and site status all combine.

When no times appear, check:

1. Business hours.
2. Service duration and buffer.
3. Staff availability.
4. Availability overrides.
5. Calendar sync conflicts.
6. Feature flags.
7. Site status.

Booking Lifecycle

Common booking states include:

Use the booking detail page for the authoritative action surface.

Lifecycle actions should have clear ownership. Staff need to know who can confirm, reschedule, cancel, mark no-show, complete, collect final payment, refund, and contact the customer. If those actions are unclear, the booking path is not operationally ready even when the public scheduler works.

Commerce Launch Checks

• Stripe connected and requirements reviewed.
• Products or services visible on the public site.
• Checkout totals match console configuration.
• Notifications are configured.
• Refund, cancellation, and reschedule policies are clear.
• Customer portal shows the resulting order or booking.

Use one representative product and one representative service for launch verification when the workspace supports both. Record the product/order ID, service/booking ID, payment behavior, notification result, and portal result so support can reproduce the launch path later.