Card readers and bill acceptors talk to VertexBooth directly. The booth authorises the card, runs the session, and voids the charge if the print fails. Nobody has to be standing there.
A mock reader is built in, so you can rehearse the whole paid flow before you buy hardware.
Takes payment from the operator, in advance, through a booking form. That is a website problem and plenty of tools solve it well.
Has to recognise a tap, hold the right amount, judge whether the session succeeded, then settle or void. Nobody is there to referee it.
We run our own unattended machines in South Florida venues. This is the part we had to build for ourselves before any of it became a product.
Every card reader, coin mech and bill validator on a snack machine speaks MDB, the vending industry’s own protocol. VertexBooth speaks it too, through a Qibixx bridge board. That board plugs into the cabinet harness on one side and the booth PC over USB on the other.
The reader tells the photo booth payment software that a card has been presented. The booth shows its own Waiting for the card screen.
VertexBooth tells the reader how much to hold, priced per strip or per sheet, set in Studio in about ten seconds.
Photos, filter, print, delivery, at the price you set for this venue, this event, or this hour of the week.
If the printer jams or the media runs out, the software voids before the charge settles. No refund argument three days later.
We have tested this against a Nayax VPOS Touch. Any MDB level 3 cashless device should behave the same way, and cash devices hang off the same harness.
The common workaround is a QR code that sends the guest to a checkout page on their phone. It is cheap to build and it looks fine in a demo. In a loud room at eleven at night, with a queue behind them, it is four actions instead of one.
Guest does
Taps the reader. One action.
Fees
Your processor rate.
When it fails
The software knows instantly. No charge and no session.
Guest does
Inserts cash.
Fees
None.
When it fails
The software knows instantly.
Guest does
Scans, loads a page on venue wi-fi, types a card, walks back. Four actions.
Fees
Processor rate plus a platform cut.
When it fails
The guest gives up mid-flow and you never find out.
Nobody publishes an abandonment rate for the third card, because nobody can measure it. That is rather the point. A tap either happens or it does not, and either way the machine tells you which.
Trading is controlled three ways. Always. Only during booked events. Or weekly hours, so Thursday and Friday six to eleven, Saturday noon to eleven, Sunday noon to eight. Outside those windows the booth shows a Closed screen with your own headline. Any session already running is allowed to finish.
An event carries its own design, its own start screen, whether printing is allowed, and whether it gates trading altogether. Photos taken during one belong to it. Overlapping bookings are flagged before they bite.
Nobody is there to notice, so the booth has to be the one that notices.
The dashboard lists sessions, prints, sends and faults for today, seven days, thirty days or one event. Payments are itemised. Faults carry their recovery time, so you can see the printer ran out at 9:40 and was earning again at 10:20. All of it exports to CSV, which is what a venue statement needs.
Our own machine at Nova Southeastern University cleared more than 300 paid sessions in its first month through exactly this flow. It also had a hardware fault early on that cost a run of refunds. The software voided those charges, so there was nothing to argue about with the guests or the venue.
Nayax and the rest sell you hardware. The merchant account behind it is a separate decision, and it sets the rate you actually pay.
Cashless readers need a signal. Most venue wi-fi cannot be relied on, so budget for the reader’s own cellular plan from the start.
Card fees carry a fixed component, so a low session price gives away more of itself. Set the price per venue and change it over remote access.
No. There is no per-session fee, no platform percentage and no transaction cut. You buy the licence once and the takings are yours. The full price list is on the VertexBooth software page.
Yes. Both hang off the same MDB harness, and the software treats them as one payment layer rather than two systems to reconcile.
That is what we have tested and what we support. If you already own a different MDB interface, tell us which one and we will say plainly whether we have run it.
Yes. A mock payment provider ships in the box, and the payment screen behaves exactly as it will with real hardware, declines included.
Yes, over remote access. A cloud dashboard that changes prices across a fleet from one screen is on the roadmap, not in the product today.
Fewer than you would expect, and the distinction between driving a reader and displaying a QR code is worth understanding before you buy. We covered it in photo booth software with card payment.
For context on the hardware side, Nayax’s own photo booth page sets out what a cashless reader expects from the machine it is bolted to. The short version is that the machine has to be able to hold, complete and reverse a transaction on its own. That is the bar, and it is the bar this software was written to clear. Payment is one part of a longer list, and the rest of it is set out on the photo booth software features page.
Free download, mock reader included. Watch a card decline, a print fail and a void happen before you spend a dollar on hardware.
