Custom product development for vending machines, kiosks and self-service devices

New device design and existing vending machine upgrades

For a new product, the display, board, power supply, motors and product path can be planned together. For an upgrade, the wiring harness, sensors, dimensions and interfaces of retained units constrain the design. Technical documentation and authorised interfaces define the new board's boundaries. Access to every function of an undocumented terminal or closed software is not assumed.

If a shared control board is intended across models, list the differing motors, channels, displays and software options. Link model configuration to board revision. Assess development costs separately from materials and assembly in repeat production. Once the model and functions validated by the first prototype are clear, the quotation becomes a reviewable project scope rather than just a PCB price.

• A new OEM device or defined modernisation scope
• Mechanical and electrical interfaces to retain
• Model options and production revisions

Dispensing mechanisms, motor control and delivery detection

Loads and motion vary between spiral, conveyor, drawer and other dispensing mechanisms. Motor type, drive method, position feedback and jam behaviour are evaluated with the mechanical design. Actual products test how package dimensions, weight and surface affect passage through the mechanism. The method for detecting a falling product or its arrival at the outlet depends on the device's physical arrangement.

Motor movement does not prove product delivery. If no product emerges, retries, channel disabling or service notifications follow the operator's rules. Transaction records manage cases in which repeating a command must not dispense a second product. Dirty, stuck or disconnected sensors are also tested. How failed delivery appears to the customer and operating dashboard is part of the software scope.

• Mechanism and channel trials with actual products
• Combined assessment of motors, position sensing and product-exit sensors
• Jam, retry and failed-delivery behaviour

Aligning the touchscreen and user flow with the device

Users should understand their selection, the transaction stage and where to collect the product. Display software includes selection, waiting, cancellation, completion and error states. Disabled or out-of-stock options are handled appropriately. An unfinished session must not carry over to the next user, and personal transaction information should not remain on screen unnecessarily.

Display position, viewing angle, touch area and distance from the collection compartment are assessed with industrial design. Service-menu motor tests and settings are separated from the customer interface. Permissions define who can change language, content or product lists. A visual prototype supports physical usability assessment, followed by integrated transaction testing with the actual board and mechanism.

Integrating the payment provider correctly with product delivery

Payment terminal or provider selection is assessed against the business model and supported integration. VOMRO connects product selection, transaction identity and device states to that interface. The design specifies payment initiation, the channel used to confirm the result and provider responsibilities for cancellations or refunds. Payment and authorisation responsibilities remain separate from device control.

An absent response does not necessarily mean a failed transaction. The result is verified using supported status queries or notifications; an uncertain transaction is not simply restarted. Payment approval and physical delivery remain separate. If dispensing fails, the record enters the correction flow agreed between the operator and provider. The scope aims to avoid unnecessary handling of card or account data by device software, and integration acceptance uses the actual terminal and test environment.

A flow that maintains transaction consistency during network and power interruptions

Define which local functions continue when internet access is lost. Offline payment acceptance is considered only under provider-supported conditions accepted by the operator; terminals are not assumed to have identical capabilities. Local selection, payment status and dispensing are tracked as separate records. The design specifies how device and server records are compared after reconnection.

If power fails mid-transaction, test how the last state is recovered at startup. The device must not replay an uncertain record as a new sale. If physical delivery cannot be confirmed, provide an inspectable state to the operator. Repeated notifications must not decrement stock twice or dispense two products. Reconciliation compares payment, delivery and stock events; showing a success message alone does not complete it.

Developing stock, telemetry and service dashboards around the operating workflow

The server application defines relationships between devices, channels, products and refill records. Successful delivery, failed attempts and manual stock adjustments are separate events. Specify how software stock counts are checked against physical refilling and dispensing. Last connection time, channel faults and maintenance information are displayed according to the operator's service plan.

Track which device applied a remote setting, with which version and when. Operators, service staff and administrators can have different permissions. Events are stored locally while offline and transferred after reconnection under ordering and deduplication rules. Updates and remote servicing are planned around power, connectivity and maintenance conditions. If the customer has existing software, its interfaces and data responsibilities are assessed without imposing a new platform.

Electronics, mechanical design and prototypes through production preparation

Motor drivers, sensor inputs, display and communication interfaces are arranged on a custom PCB for the project. Supply variations, motor-load effects on measurement and communication, connector order and service access are considered together. Board placement is checked against the cabinet, mechanism and wiring harness. Suitable 3D prototyping or manufacturing methods are selected for enclosure and mechanical parts.

Pilot tests cover different products, stock levels, jams, interruptions and return to operation after servicing. Hardware and software revisions are recorded. Production preparation defines the BOM, programming and functional checks. Prototype PCB fabrication and assembly support are limited to customer projects developed by VOMRO. A working one-off sample and testing every manufactured device are different tasks; production checks are also included in the delivery plan.

Confidentiality, source file delivery and the first technical discussion

At your request, we sign an NDA before product ideas and technical details are shared. The work is for the customer's own device and brand. Product types, mechanism, operating environment, expected production volumes and existing hardware provide a starting point. If the payment provider has not been chosen, the required interface expectations are clarified during scope discussions.

Project source code, schematics, PCB sources, mechanical CAD and technical documentation are delivered at completion. Build/programming, interfaces, data models and testing information are included in the delivery list defined at the outset. Third-party terminal, tool and library licences are explained separately. Acceptance requires the defined selection, transaction, delivery and error scenarios to work together, not simply the device to switch on.