A recommendation that doesn't reach your register is just marketing.
The guest taps to order. The ticket lands parked on the POS you already run, with the cigar and the pour on it. Your staff pulls it up and takes payment.
This is the step that separates Stack Finder from every other recommendation kiosk. Theirs suggests. Ours sends the order to your counter.
No app, no password
Nothing to install and no password to create. Guests leave an email so their order and their picks reach them — which is also how you capture the contact.
No card at the kiosk
Payment happens where it always has — at your register, with your staff. No card details entered on a shared screen.
Your POS, not a second system
The order arrives as a parked sale in the system you already close out on. Nothing new to reconcile.
The guest checks their own order first
Before anything reaches your register, the guest opens their stack and sees exactly what they are about to buy — each cigar, each pour, and what each one costs.
Drinks carry their full build: the pour size, how it is iced, the garnish, and the mixer as its own line at its own price. Nothing is folded into a bundle, so there is no argument at the counter about what was actually ordered.
Anything they have changed their mind about comes off with one tap. What is left is what gets sent.
Fewer corrections at the register, because the guest has already confirmed the order themselves.
What your staff actually sees
A parked sale appears with the guest's cigar and pour already on the ticket. Your staff opens it, confirms, takes payment, done.
Cigars park on the humidor register and the drink parks on the bar register, so each side of the house sees only its own ticket. The guest gets a short pickup code to give at the counter.
That is the entire operational change. There's no second terminal, no separate order screen to watch, and no new closing procedure at the end of the night.
If your staff can ring up a sale today, they can ring up a Stack Finder sale today.
The POS credentials never touch the browser
The kiosk is a web page, and a web page cannot be trusted with a write token to your point-of-sale. Anyone who opened the page could read it.
So orders go through a service that holds the token server-side and creates the parked sale on your behalf. The kiosk asks; it never has the keys.
Worth asking any vendor how they handle this. It's the difference between an integration and a liability.
Why it's built this way
Tobacco can't be sold through most mainstream e-commerce checkouts. Rather than fight that, Stack Finder hands the sale to the place where tobacco is legally and practically supposed to be sold — your counter, in person, with a human confirming it.
The result is a kiosk that increases basket size without putting you anywhere near a compliance problem.
The questions this always raises.
What if the guest changes their mind?
The parked sale is just a ticket. Nothing is charged until your staff rings it, so an abandoned order costs nothing and voids like any other.
Does this work with my POS?
It's built against Lightspeed today. Tell us what you run and we'll give you a straight answer on the call rather than a maybe.
Can guests pay at the kiosk instead?
By design, no. Keeping payment at the counter is what keeps the age check and the compliance picture clean.
It works with the rest of it.
See it on your own inventory.
Fifteen minutes, your cigars in the kiosk, and an honest answer about whether it fits your shop.