Can a Vending Machine Run Your Own Software? API, SDK and Controller Questions
WEIMI INSIGHTS / BUYER QUESTIONS / SOFTWARE INTEGRATION
A custom logo on the screen is very different from running your own application. Before ordering a prototype, define which software your team will control and what the machine supplier must expose for a reliable purchase.
Define the integration boundary before ordering hardware for your own customer app, cloud platform or local payment service.
APPLICATION
Who controls the customer journey?
CONTROLLER
How are commands and results exchanged?
OPERATIONS
Who supports the integrated system?
Request documentation and a working integration demonstration for the exact controller and software version. An Android screen, an MDB connection or a cloud dashboard alone does not prove that third-party software can control the complete machine.
01 / BUYER NOTES
Separate the interface, controller and cloud platform
Draw a simple map of the proposed system. Identify the customer interface, machine controller, payment service and cloud platform. State which organisation supplies and maintains each part. This makes it possible to ask a precise question about running your own software instead of receiving a general answer about customisation.
For example, your team may want to build the product selection screen while the supplier retains control of dispensing. Another project may need its own cloud to receive sales and fault events. These requests involve different interfaces and responsibilities, even when both are described as an open vending platform.
Ask whether the touchscreen permits installation of your application and which operating system and deployment method are supported. Confirm how access is authorised, how the application starts after a restart and what happens during maintenance. The ability to display a website is not necessarily equivalent to supported control of the vending mechanism.
02 / BUYER NOTES
Ask for documentation that matches the proposed controller
Request the relevant API, SDK or communication protocol documentation before approving development. Identify the controller reference, firmware version and licence or access conditions. Documentation for another cabinet or an older build may not describe the equipment in the quotation.
List the actions your application needs, such as reading product locations, requesting a vend and receiving a final result. Also list the information needed for operations: availability, faults, stock changes and service status. Ask the supplier to identify supported actions, restrictions and anything requiring additional development.
Treat interface names carefully. MDB commonly relates to communication with payment peripherals, while other interfaces serve different purposes. An MDB-compatible payment connection does not establish that an external application can command every motor or access every cloud record. Ask for the actual supported integration scope rather than relying on a familiar acronym.
03 / BUYER NOTES
Define transaction states before connecting payment
Agree how a customer purchase moves from selection to payment approval, dispensing and final completion. Identify which system owns the transaction reference and how the payment result is associated with the requested item. Keep the machine command and the financial transaction connected without treating them as the same event.
Discuss timeouts, unsuccessful dispensing and repeated messages with both the controller and payment providers. A command may be received even when its acknowledgement is delayed. Your application should not automatically issue a second vend merely because the first response did not arrive promptly. Request the supported status-check and duplicate-request behaviour.
Confirm who is authorised to initiate refunds or other payment adjustments and how the final outcome is recorded. Do not assume that a controller error automatically reverses a financial transaction. Test the agreed process through the appropriate provider environment, with clear records for successful and unsuccessful cases.
04 / BUYER NOTES
Design recovery and offline behaviour explicitly
Ask what remains possible when the cloud connection fails and whether the proposed payment arrangement permits any offline operation. Keep local machine connectivity, internet access and payment availability separate. A controller that operates locally does not prove that every payment or inventory function can continue offline.
Define how queued events are identified and synchronised when connectivity returns. The platform needs to distinguish a delayed event from a new purchase, and staff need an understandable record of unresolved outcomes. Request a demonstration of supported behaviour rather than promising customers uninterrupted operation from a marketing description.
Include restart and software-update scenarios in the prototype test. Check whether an in-progress purchase can be reconciled and whether configuration remains consistent after recovery. Agree which team investigates a fault when the screen, controller and cloud are supplied by different organisations. That responsibility matters as much as the initial successful demonstration.
05 / BUYER NOTES
Approve a prototype with measurable acceptance cases
Prepare a short acceptance matrix containing the required command or event, expected result and evidence to retain. Include a normal sale, an unavailable product, an unsuccessful vend, a delayed response and a supported recovery case. Choose cases with the responsible suppliers and use an approved test environment.
Confirm ownership and commercial terms for the integration work. Ask who maintains custom code, how version changes are communicated and whether documentation access or licences carry recurring fees. Identify any dependency on supplier-hosted services before presenting the platform as fully independent.
After the prototype passes, record the hardware and software baseline for repeat orders. New controller revisions or firmware updates can affect the integration contract. Keep a change-review process and a supported rollback or recovery route so expansion does not quietly introduce configurations that your application has never tested.
Three promises that need different evidence
Custom interface
Question: Can your approved application run on the supplied display?
Evidence: Supported deployment, startup and maintenance behaviour.
Controller integration
Question: Can your application request supported actions and receive reliable results?
Evidence: Version-matched documentation and transaction tests.
Own cloud platform
Question: Can the required data and commands operate through your platform?
Evidence: Defined event delivery, access rights and recovery responsibilities.
PRACTICAL ANSWERS
Questions about running your own vending software
Does an Android touchscreen mean I can run any vending app?
No. Confirm supported installation, permissions and the controller interface for the exact configuration. The operating system alone does not establish compatibility.
Is MDB the same as a complete vending control API?
No. Ask which functions the proposed interface exposes and how your application receives confirmed dispense results and faults.
Can WEIMI support my own software and cloud?
The answer depends on the proposed configuration and project scope. Request a technical review and written confirmation rather than assuming all models offer the same integration access.
YOUR NEXT STEP
Send a short integration brief for technical review
Tell WEIMI your target market, product formats, preferred application platform and required commands or events. Include your payment-provider plan and prototype quantity so the technical team can assess the proposed integration.
Explore equipment →Discuss your requirements →