SCO Overview and Architecture

In this article

Overview

Supported Self-Checkout Devices

High-Level Architecture

Component Roles

Communication Flow

Core Functional Capabilities

Authentication Architecture

Service Token Usage

Installation Models

Version Compatibility

Extensibility Points

See Also

The Self-Checkout Connector (SCO) is a middleware component that enables communication between LS Central and supported self-checkout (SCO) devices. It is positioned between self-checkout devices, LS Central, and Hardware Station, providing a centralized integration layer that manages communication, authentication, and device-specific behavior so that transactions and device interactions are processed consistently across different manufacturers and deployment models.

This architecture allows self-checkout devices to interact with LS Central without requiring direct access to Business Central Web Services or hardware peripherals. SCO abstracts device-specific behavior, authentication complexity, and hardware communication, providing a unified integration layer for self-checkout solutions.

Overview

The primary purpose of SCO is to enable self-checkout devices to perform sales transactions in LS Central while minimizing direct integration complexity:

  • Enable self-checkout transactions in LS Central
  • Provide a standardized interface across device manufacturers
  • Support both on-premises and SaaS LS Central deployments
  • Integrate with Hardware Station for payments and printing
  • Allow partners to extend self-checkout behavior using Feature Flags

By centralizing this logic, SCO reduces the need for device vendors or partners to integrate directly with LS Central Web Services or hardware devices.

Supported Self-Checkout Devices

The Self-Checkout Connector supports the following self-checkout device types:

  • Diebold Nixdorf self-checkout devices
  • NCR self-checkout devices
  • Custom implementations using a plugin-based architecture

Supported functionality and available Feature Flags may vary by manufacturer. Manufacturer-specific behavior is documented separately.

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, exposed by the BC Extension for SCO. 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. Because of this, the Hardware Station URL is a required configuration value during SCO installation and setup.

Communication Flow

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

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

Core Functional Capabilities

The Self-Checkout Connector enables self-checkout devices to perform the following high-level operations through LS Central Web Services:

  • Start and manage transactions
  • Add, modify, or void items and orders
  • Retrieve item, device, and terminal configuration
  • Handle staff logon and card entry
  • Print previous transactions
  • Apply business rules and restrictions using Feature Flags

A complete list of supported Web Service operations is provided in the functional reference section.

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

The Self-Checkout Connector can be installed using one of the following models. Both are supported and are selected based on customer architecture, performance, and operational requirements; in both models, the interaction with LS Central and Hardware Station remains the same.

  • 1–1 installation
    A single SCO instance is installed directly on a self-checkout device.
  • 1–N installation
    A single SCO instance is installed on a separate server and communicates with multiple self-checkout devices.

Version Compatibility

The Self-Checkout Connector must always match the LS Central major version it connects to.

For example, LS Central version 27 requires SCO version 27.

This compatibility requirement exists because SCO relies on LS Central Web Services that may change between versions.

The latest compatible SCO installers are available through the User Portal.

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.

Feature Flags can be associated with:

  • Items (for example, age-restricted sales)
  • Specific device types
  • The SCO connector itself

Some Feature Flags are generic, while others are manufacturer-specific. Supported Feature Flags are documented separately.


See Also