NewStore self-checkout uses the security architecture described in this article. NewStore operates some of the controls and you, as the retailer, operate others. This article shows where the trust boundaries sit, lists every control with its owner and status, and sets out what you operate.
Architecture and trust boundaries
Self-checkout crosses five trust boundaries.
Self-checkout architecture and boundaries
Trust boundary | What sits inside it | Who operates it |
|---|---|---|
NewStore Platform | The OpenID Connect (OIDC) provider and hosted login page, the token service, the API gateway, the catalog and price API, the tax quotation API, the promotions API, the unified order interface, the receipt API, and credential provisioning. | NewStore |
Integrator | The self-checkout application itself: a third-party application that runs on the kiosk device as a web, Electron, or native application. The platform treats it as untrusted, because it runs on a device in a public space and NewStore does not write its code. | Retailer or system integrator (SI) partner |
Store / Physical | The store manager who opens the lane, and the credentials and OAuth client ID held in the store. | Retailer |
Payment | The payment terminal, Adyen or NewStore Payments, and everything downstream of it. Cardholder data is only available with the payment service provider and not stored in the browser. | Payment service provider |
Third party | The external tax provider, which the platform reaches for jurisdiction resolution using the store address, and the external promotions provider. | Third-party provider, contracted by the retailer |
Control register
The following table describes control ownership and the shared responsibility model. Each status has a fixed meaning:
Implemented: The control is available in production.
Partial: The control exists but does not cover the whole case.
Roadmap: The control is designed or under evaluation and is not available. The compensating control is named.
Control | What it does | Owner and status |
|---|---|---|
Authorization code flow with PKCE | The kiosk authenticates through a hosted NewStore login page using OAuth 2.0 Authorization Code with Proof Key for Code Exchange (PKCE), code challenge method | Retailer or SI partner. Status depends on your build. |
Hosted login page | Store users enter credentials on a page hosted by either NewStore or a vendor such as Microsoft or Google. The self-checkout application never sees the password. | NewStore. Implemented. |
Scope validation at the service level | The API gateway validates tokens and each service validates scopes. | NewStore. Implemented. |
Tokens held in memory only | The application holds access and refresh tokens in memory. It does not write them to disk or local storage on the device. | Retailer or SI partner. Status depends on your build. |
Server-resolved pricing | Product prices come from the catalog and price API against the tenant price book. The kiosk does not set a price. | NewStore. Implemented. |
Immutable financial documents | The application writes receipts and financial documents through an immutable API, so receipts cannot be altered after generation. | NewStore. Implemented. |
Edge protection in front of the API | CloudFront sits in front of the platform API gateway and provides the first layer of volumetric and edge protection. | NewStore. Implemented. |
Cardholder data isolation | The terminal captures card data and encrypts it to the PSP. Sensitive card data does not enter the kiosk application or the NewStore platform. NewStore stores only the PSP reference, the provider, the card brand, the last four digits, and the provider account identifier. | NewStore and PSP. Implemented. |
Per-store credential issuance | NewStore issues self-checkout credentials for each user (such as a store manager) with a kiosk role assigned to them through a controlled provisioning route. Credentials are not shared across a tenant. | NewStore. Implemented. |
Tenant isolation | The platform separates tenant data, as evidenced in the System and Organization Controls (SOC) 2 report. | NewStore. Implemented. |
Transport security | All API traffic uses Transport Layer Security (TLS). No self-checkout API accepts plaintext. | NewStore. Implemented. |
Store scoping | The access token does not carry a store claim, so the application supplies the store identifier on each call. The platform enforces tenant isolation. | NewStore and retailer. Partial. Compensating control: the retailer binds the store identifier to the lane server-side. Server-side store validation is under review. |
Payment capture assertion | The order carries the PSP reference, which is the evidence that a payment occurred. The client asserts the captured or authorized status. The platform reconciles it afterward rather than verifying it at the moment of posting. | NewStore and retailer. Partial. Compensating control: reconcile against the PSP and in Omnichannel Manager. |
API logging | NewStore logs platform API activity. | NewStore. Partial. |
Input validation on integrator payloads | The platform accepts order and receipt payloads from the integrator. Stronger payload validation and sanitization at the boundary is planned. | NewStore. Partial. |
Device identity | A token binds to a store user and an OAuth client, not to a registered device. NewStore is evaluating device binding, for example mutual TLS, Demonstrating Proof of Possession (DPoP), or a machine-identity-scoped client. | NewStore. Roadmap. Compensating control: one credential per lane and a lane-to-credential register held by the retailer. |
Kiosk-specific role | A dedicated kiosk role, bound to self-checkout users and carrying only the self-checkout scopes, is a recommendation, not a product feature. | NewStore. Roadmap. Compensating control: scope trimming on the client at onboarding. |
Authentication
The self-checkout application is a public OAuth client. It runs on a kiosk device and cannot hold a secret. NewStore designed the identity model on that basis.
Login flow: A store user signs in at lane opening through a NewStore-hosted OIDC login page. The application receives an authorization code and exchanges it, together with the PKCE code verifier, at the token service. The code challenge method is
S256.Redirect URI: The callback redirects only to a URI registered against the client.
Shopper access: Only the store manager or lead associate with the kiosk role assigned signs into the self-checkout app, at the time when the lane is opened for sales. The shopper interacts with an unauthenticated screen. Self-checkout does not create or require a shopper account.
For the login flow in detail, see Authentication and setup for self-checkout.
Authorization
Each service enforces scope validation. NewStore grants scopes per client. A self-checkout client reads the catalog, quotes tax, calculates promotions, creates an order, and creates a receipt.
Token security and credentials
Token lifetime: NewStore recommends that you configure a short access token lifetime when you create the credentials for self-checkout. NewStore can revoke a refresh token, so a shorter access token lifetime reduces the impact of a token taken from a lane. See Choosing the token lifetimes.
Credentials per store: NewStore does not issue credentials per device and does not share them across a tenant.
Revocation: Revoking an issued credential is a support-assisted operation. A self-service capability for rotation and revocation is in development.
Device binding: Device binding is not available. A token binds to a store user and a client, not to a registered device.
Payments and the PCI DSS scope boundary
The payment terminal captures cardholder data and encrypts it to the PSP. Cardholder data does not enter the self-checkout application, your server-side component, or the NewStore platform. This is where the Payment card industry data security standard (PCI DSS) boundary sits. NewStore stores the PSP reference, the payment provider, the card brand, the last four digits, and the provider account identifier.
Adyen and Stripe API keys are your secrets. Key management does not change, because the payment process does not change. See Integrating payments for self-checkout.
Logging and monitoring
Platform side: NewStore logs API activity against the self-checkout surface.
Lane side: Platform logging covers the API level only. Device and store operations are out of scope.
Lost or stolen device: NewStore recommends that you enable sufficient logging on each device, so that every action is recorded if a device is lost or stolen. You manage the incident. If you cannot rotate or revoke the credentials yourself, inform NewStore so that NewStore can help.
Code security and security testing
A self-checkout deployment has three bodies of code, and they have different owners.
NewStore platform code: NewStore develops it under its secure development lifecycle and covers it with its own static analysis and dependency scanning.
Published documentation, API specification, and build guidance: NewStore reviews these before release.
Your kiosk application and server-side component: Your code. NewStore does not review, scan, approve, or accept responsibility for it. Run static analysis, dependency scanning, and secret scanning in your own pipeline, and penetration test the application before the first live lane.
The NewStore platform is subject to NewStore’s assurance program, including platform penetration testing.
NewStore publishes a plugin that enables you to build a self-checkout application with an AI coding assistant. Review, scan, and test generated code exactly as you would handwritten code. See Building self-checkout, with or without AI.
What you operate
To make the self-checkout lane safer, NewStore recommends that you implement the following controls.
Area | What you are responsible for |
|---|---|
Store scoping in the build | Send the store identifier from server-side configuration tied to the lane, and reject any request where the asserted store does not match. |
The kiosk application | Its code, its dependencies, its build pipeline, and its penetration test. |
Device lockdown | Supervised kiosk mode, no browser chrome or developer tools, peripheral ports turned off, and physical security of the device. |
Session reset between shoppers | Clear the cart, the receipt view, the session, and the in-memory token on completion, cancellation, and inactivity timeout. |
Staff intervention | Define what triggers staff intervention at a lane, and staff the store to meet it. |
Self-checkout glossary
Term | What it means |
|---|---|
AOC | Attestation of Compliance. The signed summary of a PCI DSS assessment. |
Cardholder data | The primary account number and, where present, the cardholder name, expiry, and service code. The last four digits of the card number and a payment provider reference are not cardholder data under PCI DSS. |
CDE | Cardholder Data Environment. The systems that store, process, or transmit cardholder data, and the systems connected to them. |
DPoP | Demonstrating Proof of Possession. An OAuth mechanism that binds a token to a key held by the client, so that a stolen token cannot be replayed elsewhere. |
Idempotency key | A value sent with a request so that a retry of the same request does not create a second order. |
OIDC | OpenID Connect. The identity layer on top of OAuth 2.0 used for the hosted login. |
PKCE | Proof Key for Code Exchange. An OAuth extension that protects the authorization code flow for clients that cannot hold a secret. |
PSP | Payment service provider. Adyen, Stripe, or equivalent. Owns card capture and the cardholder data environment at the terminal. |
PSP reference | The identifier a payment service provider returns for a processed payment. The evidence that a payment occurred, and the key that reconciles it. |
Public client | An OAuth client that cannot keep a secret, such as a browser application. It uses PKCE instead of a client secret. |
QSA | Qualified Security Assessor. Determines a retailer’s PCI DSS validation requirement. NewStore is not one. |
Scope | A permission granted to an API client. Self-checkout needs the catalog, tax, promotions, order, and receipt scopes and nothing else. |
Trust boundary | A line across which data passes between components under different control, and therefore the place where a security control belongs. |
Unattended terminal | A payment terminal designed to operate without an attendant present. Self-checkout lanes require one. |
Related topics