Commercial laundry #

Reference lab status: A physical CM5 and T600 DevKit have completed Stripe test-card authorisation, simulated vend and automatic capture against a production-hosted application. Real-machine actuation and live unattended payments require separate qualification. Follow the test checkout walkthrough for the exercised setup.

Why we're exploring this #

For fun, we're seeing how far we can get towards a laundromat control system using accessible industrial hardware and software we already have. We want to learn from people who own, install and maintain laundromats: machine and installation costs, cycle volumes, utilities, failures, servicing, payments and what matters day to day. The goal is to share decisions and lessons as the project develops - not announce a commercial laundry product or promise an open-source end-to-end system. Dataplicity workflows use the Dataplicity platform; individual gateway components and examples may have separate source licences.

Our current prototype architecture uses Product Applications, Device Classes, Product Processes, authorised actions and the Customer Portal. Its equipment gateway runs as managed Software on Dataplicity-OS or another qualified Linux image, using the existing agent for credentials, command transport and event delivery.

The current software work includes machine simulators, a LaundryMachine capability contract, generic read-only Modbus instrumentation, and an owner portal with Today, Sites, Machines, machine detail, Transactions and Settings. Owner controls run authorised durable Product Processes only when the mapped class and reported capabilities support them. The CM5 and T600 test-card checkout has been exercised with simulated machine delivery; physical manufacturer qualification remains a separate step. No production machine compatibility or supported wiring is claimed by the simulator package.

Provisional application architecture #

Model operators, sites, machines, vends, prices and exceptions with existing Product Records and relationships. Reusable payment orders and allocation ledgers belong to the same customer Product Instance. Processes compose payment and service delivery. Normal owner navigation should use Today, Sites, Machines, Transactions and Settings, with business impact before technical cause. Manufacturer protocols, raw registers and framework objects belong in the integrator's setup and engineering surfaces.

Each command and business event retains immutable order, payment reference where present, vend, Process, Operation and machine-command identifiers. Payment failed means never vend. Definitely failed service after confirmed payment permits compensation; an unknown service outcome requires reconciliation and must never trigger a blind duplicate vend. Preserve successful vends in a multi-machine order and compensate only the confirmed failed service.

Payment choices and remaining questions #

The Android app on a physical T600 DevKit has completed GB/GBP sandbox checkouts with automatic settlement and simulated CM5 vends. The Dataplicity application runs in production while Stripe remains in test mode. Preferred-app return after payment is awaiting Stripe Apps on Devices enablement. See the test checkout walkthrough and Payments.

The operator must be the merchant through its vendor's Stripe Connect account. Vendors supply their own keys and region through Integrations; the laundry reference uses a normal Dataplicity-owned vendor tenant. A customer Network maps to a Terminal Location. GB/GBP has been exercised in the sandbox; live unattended deployment and Spain/EUR reader testing remain separate qualification work. UX700 requires Stripe programme access and confirmation of country, connected-account charge behaviour, provisioning, unattended approval and the supported reader/POS experience. The gateway does not hold Stripe credentials or implement a separate payment service.