Website experience and configuration
Use the correct configuration layer when a customer-facing Website behaves differently across projects, businesses, customers, or external providers. This reference describes capability boundaries, not commercial plan entitlement.
Configuration layers
| Layer | Controls | Examples |
|---|---|---|
| Project | Shared ordering and account behavior | Allowed order types, verification requirements, wallet availability, reviews, and customer fields. |
| Website and theme | Presentation and deployment mode | Marketplace, franchise, single-store, or kiosk behavior; navigation; canonical business/product links; responsive layouts. |
| Business | Store-specific ordering behavior | Schedule, fulfillment availability, menu, product options, payment choices, reservations, and vertical-specific fields. |
| Customer and order state | What the current user can access | Authentication, verification, saved location, active carts, owned orders, saved addresses, and saved payment instruments. |
| Third-party provider | Provider-owned steps and outcomes | Card tokenization, payment redirects, maps, social sign-in, push delivery, and external integration authentication. |
Website modes
Marketplace
Customers normally choose an ordering context, browse businesses, open a business, and continue through product, cart, checkout, and order flows.
Franchise
Discovery can be constrained to the configured franchise. Some projects can use a franchise-specific home behavior before showing businesses.
Single store
The Website can redirect its start route directly to the configured business. Business and product links still follow the project's canonical URL templates.
Kiosk
The Website suppresses customer-account experiences that do not apply to the kiosk journey. Wallets, public marketplace discovery, and applicant signup routes are among the experiences that can redirect away in kiosk mode.
State gates
| Gate | Customer-facing result |
|---|---|
| No resolved ordering location | Discovery waits, requests a location, or returns to the start experience. |
| Sign-in required | Account, cart, checkout, and order destinations redirect to the configured start experience. |
| Email or phone verification required | The customer is sent to verification before most authenticated pages. |
| Required profile information missing | A completion flow replaces most pages until required fields are supplied. |
| Business or product unavailable | The relevant list, product, or cart state reports that the item cannot continue. |
| Third-party provider unavailable | The provider-dependent choice can be hidden, disabled, redirected, or reported as unavailable. |
Checkout and order-confirmation routes are exempt from the global profile-completion replacement so that an in-progress order does not unexpectedly switch to another page. Each checkout field can still have its own validation requirement.
Integration guidance
- Read the project's current Website links instead of assuming a route template.
- Treat client-side visibility as the customer experience, not as authorization for an API operation.
- Keep provider credentials and private configuration outside browser URLs and public documentation.
- Use the canonical API Reference for server-side authentication and request contracts.
Related references: Website routes and deep links · Integrations and external handoffs