Demo Minimal Onboarding (Reseller) - QA/Testing

Overview

demo-minimal is not a POS provider and not a feature-rich demo flow. It is one of three QA-bypass values (demo-minimal, demo-standard, demo-full) for the qa_demo_providerlocalStorage flag. The three values are identical in behaviour - there is no per-value difference.

When the flag is set to any of these values, the back-office skips merchant onboarding by forcing the onboarding state to a completed POS-connected state, so QA/Playwright can reach post-POS features (Online Ordering, menus, etc.) without performing a real POS setup.

This only takes effect in test environments. It is gated by isTestEnv (VITE_ENV is not production or staging), so it can never activate in production or staging.

Although this document is filed under the reseller context, the bypass operates on the merchant's onboarding state. There is no reseller-specific demo logic in code; the mechanism is the same regardless of context.

How it works

Set the flag in the browser before loading the back office (test env only):

localStorage.setItem('qa_demo_provider', 'demo-minimal')

With the flag set, fetchOnboardingState short-circuits the real onboarding fetch and commits a demo state instead of calling the Emily onboarding API:

{
  pos_provider: 'demo-minimal',
  phase: 'completed', // onboarding done - post-POS features accessible
  setup_steps: [],
  completed_steps: [],
  answers: {}
}

Effects of the bypass:

phase is forced to completed and setup_steps is emptied, so no discovery questions or checklist steps are presented.
The demo value is injected into the available in-house channel keys (getAvailableInHouseChannelKeys), and the demo values are added to POS_CHANNELS in test env, so the hasPOSConnected check reports a connected POS.
The Emily widget treats the flag as "QA demo mode" and lets the store state drive the phase rather than running the real onboarding flow.

To disable, clear the flag:

localStorage.removeItem('qa_demo_provider')

Prerequisites

None. This is a client-side QA bypass. It requires only:

A test environment (isTestEnv true; not production/staging).
The qa_demo_provider localStorage key set to one of demo-minimal, demo-standard, demo-full.

What this does NOT do

It does not select or connect a real POS provider. There is no demo-minimal provider in the backend (no references in backend code, config, or routes).
It does not auto-create any resources (no demo location, no sample menu/items, no mock payment configuration).
It does not run a discovery questionnaire or generate setup steps - setup_steps is explicitly emptied.
It is not driven by a ?demo= URL parameter; it is read only from localStorage.
It does not behave differently per value - demo-minimal, demo-standard, and demo-full are interchangeable.

Not verified here

The following are out of scope for this code-grounded review and were not verified against source:

Reseller signup flow.
Sales/onboarding process for resellers.
Any standalone "demo environment" provisioning outside this localStorage QA bypass.

Demo Minimal Onboarding (Reseller) - QA/Testing ​

Overview ​

How it works ​

Prerequisites ​