SCO Architecture Overview

High-Level Architecture

At a high level, the SCO architecture consists of the following components:

Self-checkout devices
Self-Checkout Connector (SCO)
LS Central (Business Central)
Hardware Station (HWST)

All communication between self-checkout devices and backend systems is routed through the Self-Checkout Connector.

Component Roles

Self-Checkout Devices

Self-checkout devices are the customer-facing terminals used to scan items, initiate transactions, and complete payments. These devices do not communicate directly with LS Central or Hardware Station.

Depending on the manufacturer, devices may support different capabilities or Feature Flags.

Self-Checkout Connector (SCO)

The Self-Checkout Connector acts as the central integration layer in the self-checkout solution.

Its responsibilities include:

Exposing a unified interface to self-checkout devices
Translating device requests into LS Central Web Service calls
Handling authentication with Business Central
Applying business rules and Feature Flags
Routing payment and printing requests to Hardware Station

LS Central (Business Central)

LS Central is the system of record for transactions, items, pricing, and business rules.

SCO communicates with LS Central exclusively through published Business Central Web Services. These services are used to manage transactions, retrieve configuration data, and apply business logic.

Hardware Station (HWST)

Hardware Station is responsible for interacting with physical hardware devices.

SCO communicates with Hardware Station when hardware-related operations are required, such as:

Processing payments through EFT devices
Printing receipts or transaction documents

All EFT terminals and printer devices are configured and managed within Hardware Station.

Communication Flow

The following sequence describes a typical self-checkout transaction flow:

A customer performs an action on the self-checkout device (for example, scanning an item).
The device sends a request to the Self-Checkout Connector.
SCO validates the request and applies any relevant Feature Flags.
SCO calls the appropriate LS Central Web Service.
If payment or printing is required, SCO sends a request to Hardware Station.
Responses are returned to SCO and forwarded to the self-checkout device.

Authentication Architecture

SCO handles authentication with Business Central on behalf of self-checkout devices. The authentication method depends on the LS Central deployment type.

On-premises
Uses NavUserPass authentication with a Web Service Access Key.
SaaS
Uses Server-to-Server (S2S) OAuth authentication.

Self-checkout devices are not required to authenticate directly with Business Central.

Service Token Usage

Each Self-Checkout Connector instance is identified in Business Central by a Service Token.

The Service Token is generated when a new Self-Checkout Connector card is created in Business Central and is used by SCO to identify itself when communicating with LS Central Web Services.

This allows multiple SCO connectors to coexist within the same LS Central environment.

Installation Models in the Architecture

The architecture supports both local and centralized deployment models:

1–1 installation
SCO is installed on the same machine as the self-checkout device.
1–N installation
A single SCO instance serves multiple self-checkout devices from a central server.

In both models, the interaction with LS Central and Hardware Station remains the same.

Extensibility Points

The SCO architecture supports extensibility through the following mechanisms:

Feature Flags defined in Business Central
Manufacturer-specific behavior handling
Custom device plugins for non-standard implementations

These extensibility points allow partners to adapt SCO behavior without modifying core transaction logic.