Dry-Contact Start Input or MDB Payment Interface: Specify the Control You Need
WEIMI INSIGHTS / CONTROLS • INTEGRATION REQUIREMENTS
Starting a function and managing a purchase are different jobs.
A requirements guide for integrating an external payment system without confusing a start signal with a complete transaction.
COMMAND
Define what action the external system requests.
FEEDBACK
Confirm what result the machine can return.
TRANSACTION
Connect the command with the payment outcome.
A requested dry-contact input and an MDB interface should not be treated as interchangeable features. Ask the suppliers to define the supported behaviour and complete integration scope.
01 / BUYER NOTES
Describe the intended action before naming the connector
State what the external system needs the machine to do after an approved event. It may request a defined service or initiate another supported operation. The exact action and its limits should be clear.
Then ask which documented interface supports that action in the proposed configuration. Avoid assuming that a terminal’s available output matches a machine’s input simply because both are described as a start signal.
This article does not provide wiring, voltage or circuit-modification instructions. Qualified authorised integrators should assess the actual electrical and technical requirements.
02 / BUYER NOTES
Separate a start request from product selection
An external request may initiate a fixed function without carrying product identity, price or quantity. Ask what information the proposed interface actually conveys and what must be configured elsewhere.
If customers can choose among several services, explain how that choice reaches the machine. A single input should not be assumed to select every menu option. The design may need a richer supported communication method.
Keep the description tied to the current documentation. Do not invent timing values or signal meanings from another model or an unrelated controller.
03 / BUYER NOTES
Ask what feedback is available
A complete operating process may need to know whether the machine accepted the request, began the action and completed it. These are different states. Ask which feedback the proposed configuration supplies.
If the interface provides no completion information, record that limitation. The payment or management system must not treat a sent command as proof that the customer received the service.
Clarify how faults and unavailable conditions are represented. The operator needs a supported way to prevent or resolve an incomplete purchase, not a guess based on elapsed time alone.
04 / BUYER NOTES
Keep payment approval and machine control connected
The payment provider and machine integrator should agree the sequence from authorisation to action and final customer message. A supported payment interface may coordinate more of that sequence than a basic trigger, but the actual implementation needs review.
Do not assume that an interface name establishes compatibility with every terminal or service provider. Confirm the exact hardware, software and version combination through the responsible parties.
Keep transaction references and records sufficient for support while limiting unnecessary payment information. The integration should allow staff to investigate a purchase without collecting full card details.
05 / BUYER NOTES
Evaluate repeated requests and interrupted operation
Ask how the system handles a delayed response, a repeated request or a restart during an active operation. The correct design depends on the supported interface and process; it should not be improvised by repeatedly sending a start signal.
Include an unavailable-machine scenario in the agreed test plan. Confirm whether the external system knows the machine cannot begin and what the customer sees. Do not promise automatic refunds or retries without evidence.
Use approved controlled testing with the relevant suppliers. Do not bypass interlocks, open electrical assemblies or deliberately create unsafe conditions to explore undocumented behaviour.
06 / BUYER NOTES
Document the integration boundary for service
List which party provides the payment terminal, control interface, configuration and final tests. The buyer should know who supports a failure involving more than one component.
Retain the approved interface specification and configuration with the equipment records. A later terminal replacement or controller update may require another compatibility review. Physical connection alone does not establish equivalent behaviour.
The final procurement answer should explain what can be commanded, what feedback is available and how the transaction is reconciled. That is more useful than a simple yes beside two interface acronyms.
Three questions for an external-control proposal
Input meaning
Ask: What exact request does the machine recognise?
Confirm: selection, quantity and supported state limits.
Output meaning
Ask: What accepted, active or completed information returns?
Confirm: actual feedback and unavailable conditions.
Payment coordination
Ask: How does the purchase reach a final outcome?
Confirm: provider integration and exception records.
PRACTICAL ANSWERS
Questions worth asking before you order
Is a dry-contact start input the same as an MDB interface?
No. They should not be treated as equivalent. Confirm the actual functions and transaction behaviour supported by each proposal.
Does sending a start signal prove the service completed?
No. Completion requires the appropriate supported feedback or another agreed verification process.
Can I wire an external terminal myself from this guide?
No. This is a requirements discussion; electrical integration belongs with qualified authorised personnel and the applicable documentation.
YOUR NEXT STEP
Specify the command and feedback you require
Share your external payment system’s authorised interface information with WEIMI. Ask for a joint review of supported control, completion feedback and transaction recovery.
Explore equipment →Discuss your requirements →