---
title: "Website experience and configuration"
description: "Understand which layer controls each customer-facing Website variation."
canonical: https://docs.ordering.co/docs/developers/website/experience-configuration/
---

# 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](https://docs.ordering.co/docs/developers/website/routes-deep-links/) · [Integrations and external handoffs](https://docs.ordering.co/docs/developers/website/integrations-handoffs/)