Storefronts

A storefront is an online shop that WaveRunner hosts for your products. Customers browse your catalogue, add products to a cart and pay by SEPA Direct Debit; the order, its lines, any subscriptions and the fulfilment work all land in the same tenant as your other orders. This guide walks through setting up a store, from the first page to the emails a customer receives after the order.

The storefront runtime talks to a runtime-internal API that is not an integrator surface; integrators use the order, subscription and webhook APIs documented elsewhere in these docs.

Creating a store

Create a store from the Storefronts area by giving it a name. You can start from one of the starter kits (a general store, a single hero product, or a subscription brand), which creates a home page, the standard selling pages, a theme and, when you have a merchant profile, six pre-filled legal pages. A store without a description takes the kit's hero lines as its description, which is also the meta description of its home page; edit it any time. Or start blank and add the standard pages yourself (home, collection, product, cart, checkout, thank you and the other selling pages).

Every store is either Draft or Published. A draft store is visible only in the editor and its preview; publishing makes the current version of every page live. Each page is edited in the visual editor: drag blocks onto the page, set their content and style, and preview the page with your real catalogue. Edits are saved as a draft and reach customers only when you publish again.

Catalogue

A store sells the products of the collections you bind to it. Products carry storefront fields besides their price: a URL slug, SEO title and description, a vendor, a tax class, a weight and whether the product is visible on the storefront at all. A product can have variants (for example size and colour), each with its own SKU, and quantity packages for volume pricing. Stock is tracked per variant: each variant has a stock level with an on hand count, a reserved count held by open checkouts, and a policy that either refuses or allows orders once stock runs out. Collections group products manually or by rules, and a store shows only the collections it binds.

Behind every product a store sells sits a managed offer on the store's payment gateway: it is the billing bridge that lets one-off products and subscriptions bill through the same gateways as the rest of your orders.

Profiles

A store links to profiles that you set up once and reuse:

• Merchant profile: your legal name, address, register entry, VAT number, contact details and EU responsible person. The legal pages of a starter kit (imprint, privacy, terms, withdrawal, shipping and payment, cookies) read these values through merchant tokens, so a change to the profile updates every page on the next publish. Every legal page is optional: you can edit or delete any of them.
• Discount profile: discount codes and automatic discounts for the store's checkout.
• Shipping profile: shipping zones by country and the rates offered at checkout.
• Tax profile: tax rates by country and tax class.
• Autoresponder profile: the email rules that send order emails for this store (see Emails below).

Publishing

Publishing runs a set of checks first. A check that fails blocks the publish and says what to fix, for example: the store has no home page or the home page is empty; a page uses a token that has no value (such as a legal page naming a merchant field your profile leaves empty); a selling page is missing, or lacks the block that sells (a product detail, an add to cart button, a cart, a payment form); a product or the gateway does not match the store's currency; or the store has no payment gateway. Warnings do not block the publish but are shown so you can decide: an inactive shipping, tax or discount profile, customer emails switched off, no email rule that sends an order confirmation for this store, or a menu item whose target page is gone.

A publish takes a snapshot of every page and the store's menus and theme. Customers always see the last snapshot: editing a page after publishing changes the draft only, and the editor shows which pages have changes since the last publish until you publish again.

Domains

Each store is served on one custom domain that you register for your tenant (for example shop.example.com), with a DNS record pointing at WaveRunner. Until a store has its own domain it can be opened on a shared preview host, which is meant for checking the store and is never indexed by search engines. Search engines index a store only on its custom domain; the store then publishes a sitemap and product data for search results.

Fulfilment

A store order that needs shipping enters the fulfilment queue at the store's fulfil point (when the order is created, or when its payment completes). From the Fulfilment page you can:

• Mark fulfilled when the order is picked and packed;
• Ship with a carrier, tracking number and tracking URL, which creates a shipment of every shippable line;
• Mark delivered once the carrier confirms delivery;
• Mark returned when a shipped or delivered order comes back, which puts its stock back once.

The queue can be exported as a CSV file for a warehouse, and a carrier's tracking file can be uploaded with the shipments CSV update to ship many orders at once (see CSV Imports). For a warehouse or a third-party logistics system, the fulfilment webhook integration sends every order that enters the queue to your endpoint and accepts a signed postback with the carrier and tracking number, which ships the order. The fulfilment events are listed in Webhook Events and delivered as described in Webhooks.

Emails

The store's autoresponder profile holds the email rules for its orders. A rule listens to an event and sends a template:

• order.created sends the order confirmation;
• order.shipped sends the shipping notice with the carrier and tracking link;
• order.delivered confirms the delivery.

Order confirmations and shipping notices of a store are in the transactional category: a customer who unsubscribed from marketing still receives them, because they are part of the order. The tenant-wide email kill switch still stops every email, transactional ones included; the publish checks warn when emails are switched off for a store that sells.

Stock and reviews by CSV

Two CSV flows keep a large catalogue up to date. The stock CSV update adjusts variant stock in bulk: match each row by sku or variant id and give either a delta (added to the stock on hand) or an absolute on_hand; every row that moves stock is recorded as a stock adjustment. The reviews import creates product reviews from a CSV file, with a dry run that reports every row before anything is created; imported reviews start as pending unless the file says otherwise. Both are covered with their columns in CSV Imports and Storefront fields.

Related pages

• Storefront fields: store settings, checkout settings, fulfilment statuses and the CSV columns.
• Session Fields: the lines and subscriptions keys of a storefront payment session.
• Webhook Events: order.created and the five fulfilment events.
• Webhooks: delivery, signatures and retries.
• CSV Imports: the import and update CSV flows.