Technical datasheet
The technical elements for an IT department, a security team or a tender.
In brief
This page gathers what an IT department, a security team or a tender will ask for: components, languages, compatibility, security, compliance.
Two points shape the rest. The architecture is tied to no hosting provider: it rests on standard building blocks, and porting means swapping the equivalent services. And no bank card number ever passes through the platform.
The platform carries no regulatory certification in itself: its architecture allows the operator or the customer to achieve compliance.
What it brings : You answer a tender or an audit with verifiable facts, without having to ask us.
In detail
The architecture is not intrinsically tied to one hosting provider: it rests on standard building blocks — containers, standard authentication, messaging, web interfaces. One implementation serves as the reference; porting to another cloud means adapting the equivalent managed services.
Cloud-side components
| Component | Technology | Service |
|---|---|---|
| Control plane interface, product-neutral | Go | Managed application service |
| Web console | React and TypeScript | Static site hosting |
| Asynchronous job runner | Go | Dedicated ARM machine, for native builds without emulation |
| Zone reconciliation component | Go | Managed containers |
| Control plane database | SQL | Managed database, authenticated by identity — no application password |
| Account databases | SQL — one database per account on a shared zone server, with its contained user | Managed database: serverless and auto-paused by default, provisioned tier optional |
| Account sites | Site server and administration interface | Managed containers, with custom domain and managed certificate |
| Account business interfaces | Go — data and alerts, selling, payment in an isolated schema | Containers and functions, on an event-driven ingestion chain |
| Online payment provider | Connector to the real provider, plus a simulated provider for demonstrations | Publisher secrets in the zone vault, merchant identifier per account |
| Object storage | Compatible with the industry standard | Managed object storage |
| Job queue | Message queue | The runner pulls jobs: no exposed entry point |
| Image registry | Container registry | Tokens scoped per team |
| Secret vault | Managed vault | — |
| Authentication | Standard identity protocol | Identity provider compatible with enterprise single sign-on |
Device-side components
| Component | Role |
|---|---|
| Operating system | The device's Linux distribution. |
| Embedded agent (single binary) | Cloud communication, deployment convergence, maintenance sessions, remote agent updates. |
| Local communication bus | Real-time communication between the device's applications. |
| Container runtime | Running the applications. |
| Local log storage | Keeping and querying application logs. |
| Cloud synchronisation | Scheduled file upload and download, processing acknowledgements, managed secrets re-read live. |
| Hardware simulator | Playing any declared "thing" — sensors, locks, readers, terminal — without hardware. |
| Application bases | Starting points for the integrator's business code, in four languages plus the interface. |
| Full-screen display | Touch display, rotation per screen, remote screen mirror. |
| Boot screen | The customer's logo at start-up. |
| Network and firewall | Cascading network configuration, and a declarative firewall closed by default. |
| USB maintenance link | A network card over the cable and a local interface authenticated by certificate: on-site configuration with no network and no rewriting. |
| Hardware contract | Declaring "things" in the configuration: the same business code against the simulator and against real hardware. |
| Android payment terminal | The third device type, companion to a box or standalone, sharing its identity with the agent. |
Application languages
| Language | Use |
|---|---|
| Go | Agent, tools, low-footprint services. |
| Node and TypeScript | Application services, file synchronisation, logs. |
| .NET and C# | Application services, hardware modules, certified payment terminal. |
| Python | Audio, language processing, local machine learning, hardware drivers. |
| Kotlin | The Android payment terminal application. |
| React and TypeScript | Touch user interface. |
A library shared across languages — bus, logging, runtime state, sessions — exposes an interface aligned on six stacks, with parity enforced within the same release cycle.
Tools
- Web console, in any modern browser.
- Command line: authentication, deployment, status, diagnosis — five binaries covering Linux, macOS and Windows, on 64-bit Intel and ARM.
- Card writing tool: writing the image to the card, standalone, with no network call and no token.
- Technician bundle: short certificate, network settings over a USB cable, remote access.
- The access client is built in, so a bare Windows machine is enough.
- Development workstation as a device: it receives managed secrets and announces itself as a device of the fleet, without receiving deployments.
Compatibility
| Devices | 64-bit ARM Linux (Raspberry Pi 4, 5, Compute Module 4, Pi Zero 2 W), 32-bit ARM Linux, 64-bit Intel industrial Linux, a development workstation declared as a device, Android payment terminal. |
| Development workstations | Linux (Ubuntu, Debian and derivatives), macOS (Intel or Apple Silicon), Windows 10 and 11 natively, with or without a Linux subsystem. |
| Development environments | Visual Studio Code on every platform, Visual Studio 2022 on Windows for advanced C# debugging, and the JetBrains family. |
Security
| Mechanism | Description |
|---|---|
| User authentication | Standard identity protocol, compatible with enterprise single sign-on through federation, with the profile created on first access. |
| Device authentication | One key per image, signed at build time, never transmitted. |
| Cloud and device communication | An encrypted channel, authenticated on every message. |
| Technician access | A short certificate — two hours by default, forty-eight at most — scoped to a device or a fleet, with the account's authority staying in the vault. Validated offline by the device, including over the USB link. |
| Secret storage | Encrypted at rest, exposed only to authorised principals within their scope. |
| Managed device secrets | No token or key remains in the configuration: a time-limited storage access, bounded to the device's scope, is minted at each heartbeat; the cloud key comes from the vault. Both are re-read live, with no redeployment. |
| Distinct device key | The ingestion key delivered to machines is distinct from the account's administration key, and its role is bounded to three entry points. |
| Scope isolation | Contexts are enforced server-side and closed by default, with a role per context. |
| Non-sequential identifiers | Random business identifiers: a sequential identifier would reveal activity volumes. |
| Image registry tokens | Scoped per team: a compromise opens one namespace, not the whole registry. |
| Isolation between accounts | Verification precedes data access, and the out-of-scope answer is "not found" rather than "forbidden". |
| Device firewall | Blocking by default, declarative and cascading. |
| Code protection | Obfuscated and compressed binaries, with no opt-out; code is never in the clear inside an image. |
Compliance
The platform carries no regulatory certification in itself: its architecture allows the operator or the customer to achieve compliance.
- Personal data protection: strict isolation per account, full traceability, erasure per account.
- Payment security: the terminal module is certified to the applicable standard.
- No card number passes through the platform: online, the card is entered at the provider.
- Only a token and a masked reference are kept.
- VAT: append-only historical rates, breakdown at the date of sale, reports replayable to a date, periodic closing and accounting export on those facts.
- Audit: a tamper-proof append-only record of configuration and production changes.
- Data sovereignty: deployment on the customer's cloud — their data and their secrets stay with them.
Some orders of magnitude
| Device heartbeat | Sixty seconds by default, configurable. |
| Interface latency, excluding long operations | Under a hundred milliseconds. |
| Retry after a failed deployment | One minute, then five, fifteen, and an hour at most. |
| Standard cloud synchronisation | A quarter of an hour, configurable; a few seconds in urgent mode. |
| Compression of distributed binaries | Around 70% reduction. |
| Lifetime of a storage access | Seven days, renewed at each heartbeat, with an alert less than twenty-four hours before expiry. |
| Detecting an offline device | Three minutes by default, adjustable, with an alert to the account when it switches. |
| Device log retention | Thirty days by default, through a nightly job, with archiving. |
| Size of the card writing tool | About seven megabytes per platform. |