Skip to main content
  • Time — 20 minutes
  • Difficulty — Intermediate
What You’ll Build: A clear understanding of every configurable element across the Cart and Client Portal, including page templates, product layouts, content overrides, design tokens, and feature visibility settings, so you can shape the customer experience from first browse through to post-purchase account management. Prerequisites: Cart 2.0 is designed to adapt to your brand and product model rather than forcing your business to adapt to a fixed checkout. Customization is handled through a combination of UI metadata, design tokens, and component-level configuration, giving teams control without fragmenting logic or introducing fragile overrides. This section covers what can be customized in the Cart and the Client Portal.

What is configurable in the Cart

The Cart is the customer-facing purchase experience, from browsing products to confirmation. Nearly every visible and behavioral element can be adjusted without rewriting core logic. You can configure the following:
  1. Layout and structure
  2. Content and copy
  3. Visual styling and branding
  4. Feature visibility and behavior

1. Layout and structure

Templates

Templates can be set on the various contexts to allow users to customise pages in their store with different layouts. These are configured through the UI Schema in your brand settings. The setting key follows this format:
@context.{page}.template
These can be set globally (*) to apply that template to all applicable pages. JSON Example:
{
	"@context.*.template": = "two-column-ltr"
}
Or by {page} context specifically, such as (@context.checkout.template) for the checkout page to use the “full” template. JSON Example:
{
	"@context.checkout.template": = "full"
}
This sets every page to use the Two Column (Left-to-Right) template. You can then override individual pages by also specifying their specific context.
  • @context.*.template = two-column-ltr > all pages default to this
  • @context.auth.template = canvas-card > login/register pages override to this
JSON Example:
{
	"@context.*.template": = "two-column-ltr",
	"@context.auth.template": = "canvas-card"
}
In this example, every page uses the two-column layout except the login and registration pages, which use the centred card style instead.
  • Login & Registration (auth)
Template Value
two-column-ltr (Default)
two-column-rtl
split
canvas-card
surface-box
enclosed
Auth template context does not support full template.
JSON Example: Registration (Split) - Full-width horizontal split. No header or footer visible. Clean, minimal design with the form centred.
{
  "@context.auth.template": "split"
}
Split registration layout
  • Product Configuration (configure)
Template Value
two-column-rtl (Default)
two-column-ltr
full
enclosed
JSON Example: Product Configuration (full) - Full-width single column. All configuration options and product details stack vertically. Good for simple products with few options.
{
  "@context.configure.template": "full"
}
Full configure layout
  • Basket (basket)
Template Value
two-column-ltr (Default)
two-column-rtl
full
enclosed
JSON Example: Basket (two-column-rtl) - Order summary on the left, product list on the right.
{
  "@context.basket.template": "two-column-rtl"
}
Two column right to left basket layout
  • Checkout (checkout)
Template Value
two-column-ltr (Default)
two-column-rtl
full
enclosed
JSON Example: Checkout (enclosed) - Checkout content wrapped in a card container. Gives a self-contained, focused checkout experience.
{
  "@context.checkout.template": "enclosed"
}
Enclosed checkout layout
  • Billing Details (billing_details)
Template Value
two-column-ltr (Default)
two-column-rtl
full
enclosed
JSON Example: Billing details (full) - Full-width single column.
{
  "@context.billing_details.template": "full"
}
Full billing details layout
  • Order Confirmation (confirmation)
Template Value
two-column-ltr (Default)
two-column-rtl
full
enclosed
JSON Example: Order Confirmation (full) - Full-width single column.
{
  "@context.confirmation.template": "full"
}
Full confirmation layout
Appendix: Template Page Contexts
ContextDefinitionsConfiguration KeyApplies To
authThe context for login, registration, and password recovery pages. It has the widest selection of available templates, giving you the most control over the first impression customers get when accessing your store.@context.auth.templateLogin, Registration, and Password Recovery pages
configureThe context for the product configuration page, where customers select options, choose billing terms, and fill in any required provisioning fields.@context.configure.templateProduct Configuration page
basketThe context for the basket page, where customers review their selected products, quantities, and totals before moving to checkout.@context.basket.templateBasket / Cart page
checkoutThe context for the checkout page, where customers enter payment details and complete their purchase.@context.checkout.templateCheckout / Payment page
billing_detailsThe context for the standalone billing details page, where customers enter or update the billing information tied to their account.@context.billing_details.templateStandalone Billing Details page
confirmationThe context for the order confirmation page, shown to customers after a successful purchase.@context.confirmation.templateOrder Confirmation page
catalogueThe context for the product catalogue page, where customers browse available products and categories.@context.catalogue.templateProduct Catalogue listing page
recommendationsThe context for the product recommendations page, where suggested or related products are shown to customers during the buying journey.@context.recommendations.templateRecommendations / Cross-sell page
* (wildcard)A global context that applies a setting across all pages at once. Any page with its own specific context setting will take precedence over the wildcard value.@context.*.templateAll pages simultaneously (can be overridden per-page)
Appendix: Template Properties
ContextComponentTemplate EnumTypeDefaultTemplate Enum Values
authsession/Login.vueSESSION_TEMPLATEStringtwo-column-ltrsplit, enclosed, canvas-card, surface-box, two-column-ltr, two-column-rtl
authsession/Register.vueSESSION_TEMPLATEStringtwo-column-ltrsplit, enclosed, canvas-card, surface-box, two-column-ltr, two-column-rtl
authsession/RecoverPassword.vueSESSION_TEMPLATEStringtwo-column-ltrsplit, enclosed, canvas-card, surface-box, two-column-ltr, two-column-rtl
basketbasket/Basket.vueBASKET_TEMPLATEStringtwo-column-rtlfull, two-column-ltr, two-column-rtl, enclosed
checkoutcheckout/Checkout.vueCHECKOUT_TEMPLATEStringtwo-column-rtlfull, two-column-ltr, two-column-rtl, enclosed
billing_detailsbilling/Billing.vueBILLING_TEMPLATEString-full, two-column-ltr, two-column-rtl, enclosed
configureproduct/Configure.vuePRODUCT_TEMPLATEStringtwo-column-rtlfull, two-column-ltr, two-column-rtl, enclosed
confirmationorder/Order.vueORDER_TEMPLATEString-full, two-column-ltr, two-column-rtl, enclosed
basket (edit)basket-product/Edit.vueBASKET_PRODUCT_TEMPLATEStringfull, two-column-ltr, two-column-rtl, enclosed

Other layout and structure settings

You can control how pages are structured across contexts such as catalogue, configuration, basket, checkout, and confirmation. These changes are driven by context settings, allowing different behavior on different screens without duplication. Configurable elements include: JSON Examples
  • Product listing layout (grid, list, column count by viewport). The product catalogue list appears with a 2-column layout. The default is a 3-column layout.
JSON Example: productListLayout column.
{
  "@context.catalogue.productListLayout": "2-col"
}
2 column product catalogue list layout
  • Visibility of sections such as categories, recommendations, or breadcrumbs. Breadcrumbs can be hidden globally. It is visible by default.
JSON Example: Breadcrumbs visibility.
{
   "@context.*.breadcrumbs": "hidden"
}
Breadcrumbs hidden on category
  • Placement of summaries, totals, and action buttons. Even when product options are selected, these will not show in your configuration summary. The default is visible.
JSON Example: productConfigOptionsSummary visibility.
{
   "@context.*.productConfigOptionsSummary": "hidden"
}
Product configuration option summary hidden
  • Step ordering and visibility within the checkout flow. Basket items can be visible in the checkout. The default is hidden.
JSON Example: basketItems visibility.
{
   "@context.checkout.basketItems": "visible"
}
Basket items in checkout visibility
  • Control how product options are displayed and selected by the customer. Renders the option selector in particular layouts. The default is radio-rows.
JSON Example: optionSelector structure.
{
	"@context.configure.optionSelector": "select"
}
Select option selector
  • Set the number of columns in the option selector when using the radio-grid layout. Displays option cards in a column grid, adjustable from 1 to 4 columns to suit your product listing layout. The default is 2-col.
JSON Example: optionSelectorGrid columns.
{
	"@context.configure.optionSelectorGrid": "3-col"
}
3-col option selector grid
  • Toggle the visibility of icons displayed alongside each selectable option. Option icons are visible by default. You can hide them to display option labels only.
JSON Example: optionSelectorIcons visibility.
{
	"@context.configure.optionSelectorIcons": "hidden"
}
  • Assign a display name to a group of options when using the select-grouped selector layout. Shows a labeled group heading within the grouped dropdown, making it easier for customers to scan and identify related options.
JSON Example: optionGroupLabel.
{
	"@data.optionGroupLabel":
}
  • Assign an icon to an option group, displayed next to the group label in a select-grouped layout. Shows a visual icon beside the group label to help customers quickly identify and differentiate option categories.
JSON Example: optionGroupIcon.
{
	"@data.optionGroupIcon": "rocket"
}
  • Control how billing term options (e.g., monthly, yearly) are presented to the customer. Renders billing terms structure accordingly. The default is radio-grid.
JSON Example: termSelector structure.
{
	"@context.configure.termSelector": "select"
}
termSelector select
  • Set the number of columns in the term selector when using the radio-grid layout. Display billing term cards in various columns. The default is 2-col.
JSON Example: termSelectorGrid columns.
{
	"@context.configure.termSelectorGrid": "3-col"
}
termSelectorGrid 3 column
  • Toggle the visibility of the billing summary shown beneath the selected term. Show a cost summary line (e.g., “Pay 12.00today,then12.00 today, then X.XX/mo”). The default is visible.
JSON Example: termSelectorSummary visibility.
{
	"@context.configure.termSelectorSummary": "hidden"
}

2. Content and copy

All user-facing text is controlled through i18n configuration in UI metadata. Content can be overridden at brand, category, product, or option level, allowing targeted messaging where it matters most. This includes: CSS Examples
  • Headings and subheadings. You can change the color of headings in your cart.
CSS Example: Text color display of headings.
{
   --text-display: #d72929;
}
Updated title color
  • Button labels and call-to-action text. Color can be changed on the text on the primary buttons.
CSS Example: Color display of primary buttons.
{
   --text-button-primary: #ff6363;
}
Updated button color
  • Empty-state messages. Color can be changed on the text when the basket is empty.
CSS Example: Core text color change display.
{
   --color-core-display: #ed1111;
}
Empty basket color change
  • Informational banners and notices.
  • Legal text references. You can create your store’s terms and conditions. For more information, follow this guide.
CSS Example: Core color of legal texts.
{
   --color-core-base: #ed1111;
}
Legal text color change
JSON Examples
  • Assign a custom image URL to a specific product option, displayed within the option selector. Show the specified image alongside the option label, giving customers a visual reference for each selectable product option.
JSON Example: optionImgUrl.
{
	"@data.optionImgUrl":
}

3. Visual styling and branding

Cart styling is controlled through design tokens rather than fixed CSS overrides. Because tokens are semantic, updating a primary color or font updates the entire cart consistently, including complex components like summaries and modals. You can configure: CSS Examples
  • Brand colors and accents.
CSS Example: Canvas color.
{
  --color-core-canvas: #a0c3ff;
}
Updated canvas color
  • Typography scale and font families. You can change the font weight for display texts. Increase for bolder headings.
CSS Example: Font weight for display text.
{
  --font-display-weight: 1000;
}
Font weight display
  • Spacing and border radius.
  • Button styles and variant colour values. You can change the primary button backgrounds, main CTAs, and key accent elements. Gradients can also be updated.
CSS Example: Button primary color.
{
	--color-primary-default: #d60e0e;
}
Primary button color
  • Badges and highlight styles. Bold promotional background for discount badges.
CSS Example: Default promo color.
{
	--color-promo-default: #43d106;
}
Default promo color

4. Feature visibility and behavior

Cart features can be enabled or disabled per context. This allows a checkout flow that feels intentional rather than generic. Examples include: JSON Examples
  • Showing or hiding product images. Product images in recommendations can be hidden from the customer’s view. The default is visible.
JSON Example: productImages visibility.
{
   "@context.recommendations.productImages": "hidden"
}
Product images hidden in recommendations
  • Displaying or suppressing recommendations. Change the product style to flush and carded.
JSON Example: productStyle carded.
{
   "@context.recommendations.productStyle": "carded"
}
Carded product style in recommendations
  • Controlling zero-price display behavior.
JSON Example: zeroPriceDisplay value. Zero-price products will display 0.00 globally.
{
  "@context.*.zeroPriceDisplay": "numeric"
}
Zero-price display numeric

What is configurable in the Client Portal

The Client Portal is where customers manage services after purchase. It shares the same architectural principles as the Cart but focuses on account management rather than conversion.

1. Branding and layout

Portal customization includes:
  • Header and navigation structure.
  • Brand identity and color system.
  • Page-level layout and spacing.
  • Consistent typography across account views.
This ensures continuity between checkout and post-purchase experience. You can find more details on client area templates in this guide.

2. Features

You can configure the features in the portal:
  1. Billing history and invoices
The portal can provide full visibility into financial history, including:
  • Invoice listings with filtering and search.
  • Invoice downloads (PDF or hosted views).
  • Payment status indicators (paid, overdue, refunded).
  • Credit notes and adjustments.
  • Transaction history.
This helps reduce support requests while giving customers transparency and self-service access to financial records. For more information, follow this guide on billings.
  1. Subscription controls
Customers can manage recurring services directly within the portal. Depending on your configuration, this can include:
  • Changing billing cycles.
  • Applying promotional codes.
  • Enabling or disabling auto-renew.
  • Managing upgrades and plan changes.
  • Viewing next billing dates and renewal pricing.
This gives customers confidence and control over ongoing commitments. For more details on subscription control, you can follow the guide on auto-renewals.
  1. Payment method management
Customers can securely manage their payment details, including:
  • Adding new payment methods.
  • Updating card details.
  • Removing saved methods.
  • Selecting a default payment method.
  • Viewing stored payment methods for active subscriptions.
All payment processing continues to be handled by Upmind’s integrated gateways, ensuring compliance and security. For more details on payment methods, follow this guide.
  1. Profile and security settings
The portal can also act as a customer account centre, allowing users to:
  • Update contact information.
  • Manage company details.
  • Configure tax or VAT information. (For the tax guide, find more information here).
  • Change passwords. (For the security guide, find more information here).
  • Manage authentication settings (including SSO, where enabled).
This centralises account management and reduces reliance on manual support intervention.

3. Messaging and guidance

Portal messaging follows the same i18n-driven approach as the cart. While messaging capabilities will expand over time, current customisation is limited to text overrides rather than structural changes. Because the Portal and Cart share the same metadata and i18n foundation, messaging remains consistent across the storefront, checkout, and customer portal.