Custom Vending Apps: Define Who Signs, Installs and Supports Each Release

01   /   BUYER NOTES

Separate application ownership from machine access

A customer may want its own interface on a vending screen while using the manufacturer’s controller for delivery. Another project may propose deeper integration with an external backend. These are different scopes, and the release process should reflect the actual architecture.

Document which functions belong to the customer application and which remain with machine software or third-party services. Running on the screen does not automatically give the app permission to control hardware, access payment data or modify safety-related behaviour. Review the supported interfaces and permissions.

02   /   BUYER NOTES

Identify the target environment before packaging the app

Request the relevant operating-system, hardware and supported deployment information for the proposed configuration. The development team needs to know what environment it is building for and which components or services must remain present.

Confirm the installation method and any application-signing requirements through the platform’s documented process. Do not bypass security controls or use informal workarounds to make a prototype run. A repeatable supported installation is part of the deliverable.

Record dependencies and required configuration without embedding sensitive credentials in broadly shared files. The responsible technical teams should agree a secure way to provision environment-specific secrets and access.

03   /   BUYER NOTES

Create one release record for every deployed version

A useful release record identifies the application version, build reference, configuration requirements and compatible machine software versions. Include the intended deployment environment and the person or team approving release.

Keep the visual interface version connected to the integration version. A screen update can change product mapping or request behaviour even if the cabinet hardware is untouched. Support staff should be able to identify exactly which combination is running.

Avoid labels such as latest as the only reference. They lose meaning after the next update. Use stable version identifiers so a reported issue can be connected to a specific deployed package and configuration.

04   /   BUYER NOTES

Test the app beyond its first successful screen

Acceptance should cover startup, ordinary customer use and agreed interruption cases. Verify what happens after a documented restart, a network interruption or an abandoned session. Use the supplier’s approved procedures and the application team’s test environment where appropriate.

If the app participates in ordering, test the handover to the transaction system and the return of the delivery result. A visually complete basket does not prove a correctly completed vend. Keep the relevant transaction references available for diagnosis.

Do not infer unattended readiness from a developer navigating the app manually. The system needs a supported startup and recovery behaviour that the local operator can understand. Record unresolved dependencies before treating the release as production-ready.

05   /   BUYER NOTES

Plan updates around live transactions

Define when a release may be installed and how the system prevents disruption to an active purchase under the supported design. The exact procedure depends on the equipment and application architecture; do not invent a universal update command.

Agree the evidence needed before and after deployment. This can include the installed version, application readiness and an authorised test of the relevant customer flow. Keep the checks proportionate to what changed.

A recovery or rollback plan should be reviewed by the responsible teams. Reinstalling an older package may not restore compatibility if data structures or configuration have changed. Use a tested procedure rather than assuming every previous version can safely be restored.

06   /   BUYER NOTES

Give support teams a shared boundary map

When a customer cannot buy, the issue may involve the app, backend, connectivity, payment provider or machine controller. Name the first-line support owner and the evidence each specialist needs. Avoid sending the operator between teams with no one coordinating the case.

Use logs and screenshots that are appropriate for the issue and exclude unnecessary customer or payment data. Record timestamps and versions so teams can align events. A video of the screen can help explain a symptom but may not reveal the underlying transaction state.

At handover, confirm access to the source or build materials according to the actual agreement, documentation ownership and support availability. Do not assume that buying hardware includes ownership of every software component or an unlimited development service.