Configure your online shop
- Last verified
- Last verified Jul 14, 2026
The online shop The customer-facing sales channel where customers browse offers, select tickets, enter checkout details, and complete payment or confirmation. is the customer-facing sales channel A setting that controls where an offer can be sold, such as the online shop, POS, back office, or an external point of sale. where people browse offers, select tickets, enter checkout details, and complete payment or confirmation.
Use this article when you are preparing a shop for launch or reviewing why customers cannot find or buy an offer.
Before you start
You need back-office The administrative area where staff create offers, manage orders, configure prices, assign resources, and review operational data. access to the Shops area and at least one offer that should be sold online.
Confirm:
- which shop domain customers will use
- which sales channel is assigned to the shop
- which events, admissions, products, or vouchers should appear
- which legal documents must be shown or accepted
- which payment methods are approved for the account
- whether the shop should be public or restricted during testing
Open Shops
In the back office, open Shops. If there is more than one shop, select the shop by Name, Domain name, and Sales channel.
Use the tabs in the shop settings to review the customer experience:
| Tab | What it controls |
|---|---|
| Branding | Logo, favicon, colors, fonts, and language switcher flags. |
| Pages | Standard shop pages for tickets, events, products, vouchers, and landing page banner. |
| Page Builder | Custom pages, page order, navigation visibility, and content blocks such as offer lists. |
| Checkout | Default booking flow, default payment method, customer fields, withdrawal flow, analytics, donations, footer, and navigation. |
| Calendar | Calendar display, remaining capacity display, price display, legend, and date styling. |
| Time Slots | Time selection display, remaining capacity display, price display, legend, and time-slot styling. |
| Code snippets | Custom CSS and HTML or JavaScript snippets such as consent manager or trusted-shop snippets. |
| Theme | Colors, typography, spacing, borders, contrast checks, and published theme state. |
Set shop access
Use Access to decide who can open the shop.
Turn on Require staff login when the shop is still being prepared or reviewed. When this is enabled, shoppers must sign in with a back-office user that can read the shop before they can view catalog, availability, or checkout.
Turn it off before public launch unless the shop is intentionally staff-only.
Configure branding and theme
Open Branding and check:
- Logo
- Favicon
- Primary color
- Secondary color
- fonts
- Show flags in the language switcher
Open Theme when the shop needs more detailed control over Colors, Typography, Spacing, Borders, Button Colors, Semantic Colors, Media, and WCAG contrast checks.
If the theme editor shows unpublished changes, use the theme publish action only after you test the shop on desktop and mobile.
Configure pages and navigation
Open Pages and confirm which shop pages are active. Standard page types include Tickets, Events, Products, and Vouchers.
Use Activate this page to control whether a page is available. Use Display the filter bar underneath the page title when customers need filtering for larger catalogs.
Open Page Builder for custom pages and navigation. Check:
- page order in the page builder list
- whether important pages are Shown in navigation
- whether the home page contains an offer list or clear route to the first offer
- whether offer lists include the events, admissions, products, or vouchers customers need
- whether page titles, descriptions, and call-to-action labels are customer-friendly
Configure checkout
Open Checkout and review Checkout configuration.
| Setting | What to check |
|---|---|
| Default booking flow | Choose whether dated offers start with Date/time first or Quantity first unless the offer overrides it. |
| Default payment method | Choose the payment method used for new shop orders unless a sales channel or explicit checkout action overrides it. |
| Checkout fields | Set configurable customer fields to Automatic, Hidden, Optional, or Required. |
| Shipping address | This field is always Automatic. It appears and becomes required only when the cart contains products that must be shipped. |
| Show withdrawal flow | Shows the withdrawal button in the shop footer and allows customers to open the withdrawal page. Disable it only when your legal setup supports hiding it. |
| Analytics | Choose Privacy-preserving, Consent-managed, or Disabled for booking analytics and e-commerce events. |
| Donations | Enable only when a configured product should appear as a cart donation section. |
| Footer | Confirm social links, inherited URLs, and legal link visibility. |
| Navigation | Configure header behavior, including Hide header when scrolling down. |
Keep required checkout fields limited to information your team actually uses. Required fields can block checkout if customers do not understand why they are needed.
The shipping address is not an optional checkout setting. KORONA Event collects it automatically whenever delivery is required:
- If the billing address is visible, including when a checkout rule makes Automatic visible for this cart, the customer can use it as the shipping address or enter a different shipping address.
- If the billing address remains hidden because Automatic does not require it for this cart, or because Hidden is selected, checkout shows a separate required Shipping address section.
- If the cart does not contain products that must be shipped, checkout does not show shipping address fields.
Choose the checkout result
The shop default controls the normal checkout path. Set a different Checkout policy on an offer only when that offer should create a request, an unpaid reservation, or a booking instead of following the default.
Checkout policies
Checkout policy controls the operational result created when a customer submits the cart.
| Option | What it does | When to use it | Watch out for |
|---|---|---|---|
| Request only | Creates an order in the requested state for staff review instead of confirming a booking. | Use it when staff must review availability or another condition before accepting the order. | A requested order is not a confirmed booking. |
| Reserve unpaid | Creates a reservation that holds capacity until its deadline or next action. | Use it when customers should hold places before payment or staff confirmation. | The reservation can expire; check its deadline before promising that capacity remains held. |
| Book and continue to payment | Books the order and continues into the configured payment flow. | Use it for normal checkout where the booking is created before or alongside payment. | Booked is an operational state and does not by itself prove that payment succeeded. |
Choose ticket grouping on the offer
Ticket grouping is configured on the event, event template, or admission rather than on the shop. Use it when the customer should receive one ticket per attendee, pricing, or order item.
Ticket grouping options
Ticket grouping controls how attendances from one order item are combined into customer-facing tickets.
| Option | What it does | When to use it | Watch out for |
|---|---|---|---|
| Individual tickets | Creates one ticket for each attendance unless a product setting groups selected tickets more narrowly. | Use it when each attendee should receive and present a separate ticket. | Product-level ticket settings can still affect selected products. |
| One ticket per pricing | Creates one ticket for each pricing in the order item. | Use it as a broad shortcut when attendances with the same pricing should share a ticket. | Use product-level settings instead when only selected products or group price rules should be grouped. |
| One ticket per order item | Creates one ticket for the whole order item with detail rows for its included pricings and products. | Use it when one customer-facing ticket should represent the complete booked item. | Confirm that admissions staff can check in the grouped ticket as intended. |
Add legal documents
Open the account legal notice area when you need terms, privacy, imprint, withdrawal instructions, accessibility statements, or other legal documents.
For each legal document, confirm:
- customer-facing Name
- whether it is Required to accept at checkout
- Checkbox label
- language variants
- whether the document is shown as text in the shop or linked by URL
Confirm offer visibility
An offer appears in the shop only when its own setup and the shop setup agree.
Check the offer first:
- it is not archived
- it is published at the right time
- the Hide from shop setting is not unintentionally turned on
- it has future availability or an active sellable state
- it has at least one active price
- the price is visible on the shop's sales channel
- capacity and resources allow the selected quantity
Then check the shop:
- the shop has the right Sales channel
- the relevant standard page is active or the custom page contains the offer
- the page builder offer list or navigation lets customers find it
- search and category/filter settings match how customers will browse
Open the customer booking flow with a realistic ticket quantity and price selection. The calendar and time-slot picker recalculate availability for that selection, so a date can be unavailable even when the offer itself is visible.
Add snippets only when needed
Use Code snippets for controlled customizations such as consent managers, analytics tags, trusted-shop badges, small custom CSS adjustments, or partner scripts.
Use Add custom CSS for styling changes that cannot be handled by theme settings. Use Add HTML/JavaScript snippet only when the script is approved and tested.
Expected result
Customers can open the public shop, find the intended offers, understand price and availability, complete checkout with the required fields and legal agreements, and create an order with the expected payment or confirmation result.
Check your work
Open the public shop URL and verify:
- the domain loads without requiring staff login, unless the shop is intentionally restricted
- logo, colors, fonts, and language controls look correct
- navigation and pages lead customers to the right offers
- offer cards show the expected name, image, price, date, availability, and status
- Add to cart, View cart, and Proceed to Checkout are reachable
- required checkout fields and legal agreements are clear
- a merchandise order shows a required shipping address, either with the visible billing address or as standalone fields when billing remains hidden
- payment or confirmation behavior matches the expected checkout policy
- confirmation emails, tickets, and order records are created as expected in a test order
Troubleshooting
| Problem | What to check |
|---|---|
| Customers cannot open the shop | Domain, shop deployment, Require staff login, and whether the customer is using the intended shop URL. |
| An event or product is missing | Offer publishing, Hide from shop, sales channel, active prices, capacity, page builder offer lists, page activation, and filters. |
| A category or filter is missing | Pages, page builder configuration, offer tags/categories, and whether enough matching offers are active. |
| Checkout asks for too much information | Checkout configuration, checkout fields, event questions, attendee questions, waiver setup, and required legal documents. |
| A shipping address is not shown | Confirm the cart contains an active merchandise or shipping-required product. Shipping fields stay hidden for carts that do not need delivery. |
| Payment methods differ from expectations | Default payment method, offer checkout policy, payment provider setup, payment-link behavior, and payment method eligibility. |
| Tracking or snippets do not run | Analytics mode, consent manager behavior, snippet placement, browser consent state, and whether checkout pages allow the script. |
| Mobile layout looks wrong | Theme, custom CSS snippets, image ratios, page builder blocks, and long text labels. |