Smart cart
Customization
Overview
The shopreme Smart Cart app can be adapted to your brand, following your branding colors and logo.
This article explains which parts of the Smart Cart app can be adjusted, as customizations include not only branding but also UX features and other functionalities. It is meant as a reference you can come back to when planning your rollout or preparing a change request.
One app, many brands
There is only one Smart Cart app. Every retailer runs the same app package: the same build, the same version, the same update cycle.
Your brand's version is created by a configuration package: a .zip archive containing a configuration file together with your fonts and images. The package is pushed to the tablets from the shopreme Management Console, the app picks it up, and the interface is redrawn with your colors, your logos, your wording, and your chosen feature set.
This is what makes rollouts fast and updates safe: you receive every improvement and fix we ship without waiting for a special custom build, and the same tablet can be rebranded by replacing a single archive. It also defines the limits of what can be adjusted: the configuration can change how the app looks and which of its features are active, but it cannot add capabilities that are not in the app already.
When customization happens
Customization is usually done once, at the beginning of the project, during setup. You tell us what changes you need, we assemble and test the configuration package, and it is uploaded to all registered devices for verification.
After go-live, the settings can still be changed, but not on the fly: feature flags and timing values interact with each other, with the hardware and with the checkout flow, so every change is reviewed, tested and scheduled by shopreme. Certain changes to the checkout flow should be treated as project decisions rather than quick changes.
Anything not listed on this page is not a configurable option. If you are looking to change a behavior, a screen, or a data flow that the app does not already have, we are happy to discuss it with your project team so it can be scoped, estimated, and planned.
Look and feel
Colours
The app uses a defined color scheme rather than individual color values scattered across screens. You supply your brand palette, and we map it to the scheme: primary, secondary, the "on" colors that sit on top of them (onPrimary, onSecondary, and so on), plus background and surface colors.
Because the palette is applied through the scheme, a single set of values styles the whole app consistently: buttons, badges, panels, highlights, and price tags all follow it. This also means that sometimes changing the color of one element may not be possible without affecting other aspects of the UI. This could be a reason for rejecting a change request.
Fonts
Your brand font can be bundled into the configuration package and used throughout the app. Please supply the font files along with the license that covers their use on in-store devices. Our apps require Regular, Medium, Semibold, and Bold font files.
Logos, icons, and illustrations
Several image slots can be replaced with your own artwork. Anything you do not supply keeps the shopreme default.
Slot | Where it appears |
|---|---|
Smart Cart logo | The idle screen (while charging) |
Side panel toolbar logo | Top left of the cart side panel, replacing the "For you" title |
Loyalty card illustration | In the locked screen if there is customer loyalty information |
Loyalty icons (full and half) | Loyalty banner on the cart side panel |
Wording
Most of the text in the app is built into the app itself, and that text can be rewritten if it does not match your brand voice and tone: button labels, headings, instructions, or help texts. If you call it a "club card" rather than a "loyalty card", the app can say club card. Wording is set per language, so each market can have its own tone.
Some text cannot be changed through configuration. Anything produced by a process rather than displayed as a label, such as messages returned by the backend (e.g., unlocking, payment, or scanning errors), comes from outside the app. The app only displays what it receives. Changing those texts may require additional effort outside these configurations (backend development), and this needs to be planned with the project team.
Features and behavior
Features are switched on and off, and tuned, in a JSON configuration file. Some are simple on/off flags, some are values such as a timeout in seconds, and some are lists. The sections below cover the main groups and the settings customers most often ask about.
Cart interaction
How shoppers work with their cart on the cart screen.
Setting | What it controls |
|---|---|
Category browsing | Whether shoppers can browse products without barcodes and add them to the cart without scanning. |
Manual quantity increase button | Shows a +1 button so a shopper can add another unit without scanning it again. |
Manual quantity decrease button | Shows a −1 button to reduce a quantity without re-scanning. |
Product removal button | Shows a button that allows the removal of any product position by scanning its barcode. If disabled, the product should be removed from the delete button in its position. |
Savings breakdown | Whether tapping the savings summary opens a detailed list of the individual promotions applied. The summary total itself is always shown when the cart has savings. |
Negative evaluation | Whether a shopper can proceed to payment when the cart total is zero or below, for example, because a discount covers the entire amount. |
The quantity and removal buttons are worth a deliberate decision: they make correcting a cart much easier for shoppers, and they are also the settings most closely tied to your loss prevention approach.
Session
Setting | What it controls |
|---|---|
Session restoration | Whether a session can be restored automatically if the app is closed and reopened unexpectedly. |
Session restoration age limit | How many minutes an interrupted cart stays eligible for restoration. |
Inactivity timeout | How long the cart waits, in seconds, before asking "still shopping?". Default: 1800 |
Inactivity decision timeout | How many seconds the shopper has to answer that question before the cart is locked. Default: 60 |
Inactivity timing shapes how the cart behaves when a shopper walks away without paying, so it is usually set together with your store's process for handling abandoned carts.
Payment
Setting | What it controls |
|---|---|
Pre-payment confirmation | Whether a confirmation dialog appears before the shopper moves to payment, asking "Have you scanned everything in your cart?" |
Success screen timeout | How long the payment success screen stays on the tablet before it can go back to the idle screen. This is only applicable for Smart Carts on |
Success screen timeout after feedback | How long it stays once the shopper has submitted feedback |
Success screen timeout after webview interaction | How long it stays if the shopper interacts with a post-purchase webview |
The success screen timings decide how quickly the tablet is ready for the next shopper — short enough to keep carts moving, long enough that nobody feels rushed away from their receipt.
Digital flyer
For the in-cart flyer: the maximum zoom level a shopper can pinch to, and the maximum pixel size of a rendered flyer page. Both mainly affect how sharp large flyer pages look and how much memory they use on the device.
Loss prevention
Loss prevention combines camera and weight-sensor signals (depending on hardware availability) to flag items that may have gone into the cart without being scanned. The whole pipeline can be switched on or off, and the parts of it are configured separately. However, the default implementation is already fine tuned and it rarely requires modification.
Setting | What it controls |
|---|---|
Loss prevention enabled | The master switch for the whole pipeline. Turning camera vision on or off completely. |
Personal items tutorial | Whether shoppers are guided, at the start of a session, to scan the personal items already in the cart, to prevent false positives during the shopping journey. |
Visual proof | Whether the captured photo or video is shown to the shopper in the alert, so they can see what was flagged. |
Upload video proofs | Whether the recorded proof of each flagged event is uploaded to the shopreme backend for further processing. |
Minimum detection confidence | How confident the model has to be before an event is raised. Changing this value is not allowed as it has been fine-tuned to a level that does not raise false positives but also does not ignore real events. This requires alignment with the hardware-AI-model provider. |
Scan event timeout | A grace period after an alert during which further additions are not flagged |
The thresholds are the sensitive part: lower them and you catch more, but you also interrupt honest shoppers more often. We normally start from the defaults and tune them against real store data rather than setting them up front. They may also require some alignment with the hardware provider, as the AI-models are not managed by shopreme.
Terms and conditions
You can supply a terms of service URL and a privacy policy URL, and choose whether shoppers confirm them as two separate tick boxes or as one combined confirmation. The feature is active as soon as either link is set; leave both blank, and no terms and conditions screen is shown at all.
Retail media
If you run retail media content in the cart side panel, the maximum height of the creative carousel is configurable as a percentage of the available side panel space, so ads can be given more or less room relative to the rest of the panel.
Loyalty point display
How loyalty or reward balances are shown on price tags and receipts:
None:no loyalty balance is displayed
Currency: the balance is formatted like a price
Points: a custom number format, so you can set your own decimal and grouping separators
Shopper tips
Shopper tips are the short help cards that explain how to handle particular situations: items without a barcode, items sold by weight, large items, gift cards, loyalty, payment.
It is possible to choose which tips are available in the Help section and the order in which they appear. The order matters: tips appear to shoppers exactly as listed, and the first one is promoted as a highlight on the Smart Cart dashboard, so put the situation your shoppers struggle with most at the top. Leaving the list empty switches shopper tips off entirely.
Side panel content
The side panel next to the cart can host additional content, including the shopping list feature, which lets shoppers scan a handwritten list and work through it in the app, and recipes, which fills the panel with recipe content. Which panels are active is part of your configuration.
What configuration cannot change
To save everyone time later, these are the things that are not configuration:
New features, screens or panels. If it is not in the app, it cannot be switched on.
The structure of the app. Screen layouts, the order of the shopping and payment flow, and where elements sit cannot be configured with the steps in this guide.
Backend messages, including error messages, or unlocking error responses, come from outside the app.
Anything requiring new data. If a feature needs product, promotion, loyalty or customer data that is not already flowing to the cart, an integration has to be built first.
If you wish to add more functionality to your app, reach out to your shopreme integration consultant to define the scope, effort, and timeline, and we will be happy to improve the shopping journey for you!
Requesting a change
Configuration is agreed once during setup, so the best moment to raise anything on this page is while your project is being planned.
If you need a change later, please raise a Technical Support question via help.shopreme.com with the following information:
Which setting you want changed (you can refer to the items in this article)
The value or behavior you want instead
What you are trying to achieve, and by when. We would like to understand the reason for the change, to discuss it with our UX team. There could be requests that collide with recommended UX practices, so the shopreme team will always provide feedback if a request is not advised.
The reason matters as much as the request. It often turns out that the outcome you want is already available through a different setting; and when it is not, knowing the goal is what lets us tell you quickly whether it is a configuration change or a development topic.
