Comparing vending payment and telemetry suppliers: the ten rows that decide it
Put three quotes side by side and the brochures say the same thing: every card scheme, every machine, real-time dashboard, 24/7 support. What actually separates suppliers never reaches the quote — who holds the acquirer relationship, where telemetry originates, who owns the data, and what leaving costs. Ten dimensions, and how to verify each one before you sign.
Ask three suppliers for a proposal and read the three documents back to back. They will tell you roughly the same story: every card scheme supported, compatible with any machine, real-time dashboard, 24/7 support, open API. Different covers, same sentences.
That convergence is not dishonesty. In unattended payment and telemetry, anything that can be written in a brochure is true of everyone; the things that separate suppliers sit outside the quote entirely. The ten rows below are where you feel the difference eighteen months after signing — and every one of them can be checked before you sign.
First, decide what you are buying
Payment and telemetry are sold both as two products and as one. Before comparing prices, make sure the columns hold the same thing. Two boxes means two SIMs, two dashboards, two versions of the same sale and two companies to call when a machine goes quiet — we've written about what that clutter costs separately.
Whichever way you go, a device price cannot be compared against another supplier's device-plus-telemetry-subscription total.
The comparison table
Open one column per supplier and fill in these ten rows. A blank cell is not a missing answer — it is a question nobody has asked yet.
| Dimension | Why it decides the deal | How to verify it |
|---|---|---|
| Machine coverage | Working with a new MDB machine is the easy case. Your fleet is not all MDB: there are Executive machines, pulse and dry-contact machines, and PLC-driven lines. | Name three hard machines from your own fleet, make and model, and ask whether they run. Ask for the protocol by name, not a compatibility sentence. |
| Retrofit | Compatibility conditional on buying new machines is not compatibility. In most fleets the majority of cabinets are over ten years old. | Ask whether a ten-year-old electromechanical machine connects without being replaced. The answer should include a modernisation path. |
| Scheme coverage | Credit and contactless are universal. The revenue often sits in the local schemes — meal and canteen cards, campus and closed-loop cards, transit cards — which differ by country. | Ask which schemes are live in production, not on the roadmap, and ask for one working reference per scheme in your market. |
| Acquirer and certification | Who holds the EMV certification and the acquirer relationship? Can you keep your own acquirer, or are you moved onto theirs? This determines your rates and your PCI scope. | Ask what happens when a new scheme is added: if the answer is not “nothing on your side”, the work is yours. Get the PCI boundary in writing. |
| Where telemetry originates | Does telemetry come out of the payment path itself, or from a second box? This decides how many different sales figures you see at the end of the day. | Ask whether the payment report and the telemetry report are produced from one record. If they are two systems, ask who reconciles the gap. |
| Offline behaviour | Does the machine keep selling when the link drops? A cloud-dependent architecture fails at the busiest moment. | “No network — does a card go through, where is the data held, what happens when the link returns?” Insist on all three answers. |
| Reconciliation | When cash and cashless come from the same record, the day's close becomes a check rather than a monthly spreadsheet exercise. | Ask for one day's sample report and look for cash, card, closed-loop and refund lines in the same place. |
| Data ownership and export | Is the data yours or theirs? When you leave, does the sales history leave with you? | Read the ownership clause. Confirm you can pull the full history through an API or a bulk export, not a screenshot. |
| Pricing model | A device fee, a monthly subscription and a per-transaction commission are three very different curves. As revenue grows, commission quietly becomes the most expensive one. | Give your real monthly volume and average basket, and have them model 36 months of total cost. One monthly figure is not an answer. |
| Exit cost | Is the device locked, how long is the term, what do you pay to leave? This row sets your margin for being wrong about the other nine. | Ask for contract length, early-termination charge and who owns the hardware — in writing. |
Rolling out in more than one country
If the fleet crosses borders, three rows above change shape. Acquiring is usually local: ask whether one platform can sit on several acquirers, or whether each country becomes a separate integration. Connectivity is a real line item once roaming SIMs are involved — ask how a fleet of a hundred machines in three countries is provisioned and what the per-machine monthly data cost is. And scheme coverage rarely travels: the closed-loop card that carries half your revenue in one market may not exist in the next. Ask for the country-by-country list, not a global claim.
Three costs that never appear on the quote
Even with the ten rows filled in, the total is incomplete. Three items are almost never priced:
Connectivity. When every box carries its own SIM, the monthly data bill per machine approaches the device cost as the fleet grows. Multiply by machine count and by 36 months.
Field visits. In a system that cannot be updated remotely, every software change is a van, a technician and a day. Across a hundred machines, one update round usually costs more than a year of subscription.
The number of people you call during a fault. If payment comes from one company, telemetry from another and the machine from a third, deciding whose problem it is becomes your job. This is the item nobody invoices you for and you pay the most.
Five things to ask for in a demo
Presentations go well. The difference shows up in questions whose answers have to be demonstrated:
- "How many machines are you running in production, and how many distinct makes?" Ask for the number and the list. “Compatible with everything” is not an answer.
- "Open a live machine in the dashboard." Not a screenshot — a device connected right now. Look at the time of its last transaction.
- "Show yesterday's cash and card totals for that machine on one screen." If it takes two tabs, reconciliation will be your job.
- "Pull the network cable, make a sale, plug it back in." Ten minutes, and it settles the offline claim for good.
- "Push a software update to this device now." If OTA exists it gets shown; if it doesn't, the answer gets long.
Summary
What separates unattended payment and telemetry suppliers is not the feature list but the answer to three questions: does your hardest machine run, do you see one number at the end of the day, and what do you lose when you leave? If those three are clear the rest is detail; if they are not, the length of the feature list means nothing.
Fill in the table and give us a column too. Send the make and model of your most awkward machine and the schemes you need, and you'll get an answer with a protocol name and a field reference attached. Where we don't fit, you'll hear that with the same precision — talk to engineering, or start with the payment and telemetry pages.