How a Self-Ordering Kiosk Works with Square

A self-ordering kiosk on Square is an iPad app that reads your menu from Square, lets guests build their order on screen, and sends that order to Square. Payment happens on a Square Terminal next to the iPad, so card data never touches the kiosk. The paid order is recorded in your Square account.

That’s the short version. The rest of this post is the long one: which Square APIs do each job, the rules Square enforces along the way, and the design decisions we made building our own kiosk for independent cafés and restaurants. Everything about Square’s APIs below comes from Square’s developer documentation as of October 2026, linked at the bottom.

The five demos on our kiosk page run on sample menus for fictional shops. The Square connection described here is the architecture we’re building against.

What is a self-ordering kiosk?

A self-ordering kiosk is a touchscreen, usually an iPad on a counter stand, where guests browse the menu, pick their options and place an order without waiting for a cashier. It replaces the “what can I get you?” part of the counter. The kitchen still makes the food, and on Square the payment still goes through Square hardware.

What makes one kiosk different from another is mostly two things: where the menu comes from, and where the order goes. On Square, the answer to both is your Square account.

The four steps, from Square menu to paid order

Every order on a Square kiosk passes through the same four steps. Each one uses a different part of Square’s API.

Step	What happens	Square API
1. Connect	The shop authorizes the kiosk to use its Square account	OAuth
2. Menu	Items, prices and modifiers are pulled from Square and kept in sync	Catalog API
3. Order	The guest’s cart is priced and created as a Square order	Orders API
4. Payment	The order is sent to a Square Terminal for the guest to pay	Terminal API

One rule runs through all four. In our design, the iPad never talks to Square directly. It talks to our backend, and the backend holds the shop’s Square tokens and makes every Square call. If someone walked off with the iPad, they’d have a menu app, not access to your Square account.

Step 1: Connect the Square account

The shop owner signs in to Square and approves the kiosk app, the same OAuth flow any Square app uses. Square hands back tokens that let the app act on the shop’s behalf with the permissions the owner approved.

We keep those tokens on the server, encrypted, and request only what the kiosk needs. Reading the catalog needs ITEMS_READ, for example, and following Terminal payments needs PAYMENTS_READ. A shop with more than one location pairs each iPad to one location, so the right menu shows at the right counter.

Step 2: Pull the menu from the Catalog API

Square’s Catalog API holds your menu as typed objects. The ones a kiosk cares about are ITEM (a cortado), ITEM_VARIATION (small or large), CATEGORY (coffee, pastries), MODIFIER_LIST with its MODIFIER options (milk choices), TAX and IMAGE.

The modifier rules are what make or break a kiosk. In Square they live on the modifier list:

• min_selected_modifiers is how many options the guest must pick. Set it to 1 and the choice is required.
• max_selected_modifiers is how many they can pick, where 0 means no limit.
• on_by_default on a modifier pre-selects it, like whole milk on a latte.

Square’s own example is a latte: milk is required with a minimum and maximum of 1, and espresso shots are optional and capped at 4. A kiosk that reads these fields can enforce the same rules your cashier does. On our kiosk, “Add to order” stays disabled until every required choice is made, and it shows the guest which choice is missing.

Keeping the menu in sync

When anything in your catalog changes, Square sends a catalog.version.updated webhook. It carries only a timestamp, not the change itself. So the backend calls SearchCatalogObjects with begin_time set to the last time it synced, picks up everything that changed, and tells the kiosks to refresh.

That’s why the menu is never typed in twice: a price you change in Square reaches the kiosk on the next sync.

Step 3: Price and create the order

While the guest builds their cart, the kiosk shows a running price. Before the guest confirms, the backend can ask Square for exact totals with CalculateOrder, which previews pricing and tax without creating an order. Square marks this endpoint as beta.

When the guest confirms, the backend calls CreateOrder with the line items, their modifiers and the location. Each request carries an idempotency_key. Square describes it as a value that uniquely identifies the order, and resending a request with the same key doesn’t create a duplicate. We derive the key from our own order id, so a flaky café Wi-Fi retry can never put the same latte in the kitchen twice.

Step 4: Payment on a Square Terminal

The kiosk doesn’t take cards itself. The backend calls CreateTerminalCheckout and passes the order_id from step 3, and the Terminal beside the iPad lights up with the amount. The kiosk shows “Pay at the terminal.”

Square enforces a few rules here, all from its Terminal API docs:

• The order must be OPEN.
• In the default mode the checkout amount must equal the order total, and the order moves to COMPLETED automatically when payment completes.
• Paying for an order this way needs Square Terminal version 6.62 or later.
• Once the checkout is IN_PROGRESS, the order can’t be edited. To change it, you cancel the checkout first.

The backend follows the payment through the terminal.checkout.updated webhook. The checkout moves through PENDING, IN_PROGRESS and then COMPLETED or CANCELED, and the kiosk shows the matching screen. Square recommends webhooks over polling in production because a checkout can take a while to finish.

Pairing the Terminal with the kiosk app is a one-time job. The backend requests a device code with CreateDeviceCode (product type TERMINAL_API), and the shop signs in to the Terminal with that code. In Square’s example response, the code’s pair_by deadline is five minutes after it’s created, so pairing is done on the spot.

What are the payment options at a self-ordering kiosk?

On a Square kiosk built this way, the guest pays on the Square Terminal, so the options are the card and wallet payments Square Terminal accepts in your country. Square lists the US, Canada, Australia, the UK and Japan for some Terminal payment features, and Japan adds PayPay QR and e-money.

Cash is the exception. Square’s Terminal API docs say the Terminal can’t take cash, so a cash guest pays at the counter. Handing payment to the Terminal also keeps the iPad out of card handling entirely, which is the main reason we chose it for our first version over taking payments in the app.

What the guest sees

All of the plumbing above exists so the guest never notices it. On our kiosk, an order goes like this:

1. The welcome screen asks English or Spanish, and the guest can switch on any screen after that.
2. They pick an item and its options, with your Square modifier rules enforced as they tap.
3. The kiosk offers one add-on at a sensible moment, like a pastry with the coffee, and then moves on.
4. They confirm, and the screen says to pay at the terminal.
5. If they walk away mid-order, the kiosk asks “Still there?” and resets for the next person.

You can try that flow on the live demos, ideally on a tablet. The menus are samples, but the screens are the real app.

Questions

Does a self-ordering kiosk need its own POS?

Not when it’s built on Square. The kiosk reads the menu from your Square catalog and creates the order in your Square account, so Square stays your POS. The kiosk is one more place orders come from, like your counter or your online store.

What happens if a guest walks away while paying?

The backend cancels the Terminal checkout with CancelTerminalCheckout. If the guest hasn’t started paying, Square moves the checkout straight to CANCELED. If they have, it goes to CANCEL_REQUESTED first and only cancels if the payment isn’t finished. The kiosk then resets for the next guest.

Can a self-ordering kiosk take cash?

Not through the Terminal. Square’s Terminal API documentation says Square Terminal can’t take cash; cash payments go through the Payments API instead. In practice that means a guest who wants to pay cash orders at the counter.

Can the kiosk menu be in Spanish?

Yes, but the Spanish copy has to live somewhere. Our design stores each translation keyed by the Square object id, and flags it for review when the item changes in Square, so a renamed item never shows an outdated Spanish name.

Sources

• Square, Terminal API overview
• Square, Take payments with the Terminal API
• Square, Take payments for orders
• Square, CreateDeviceCode reference
• Square, What the Catalog API does
• Square, Enable modifiers on items
• Square, Sync your external catalog (webhooks)
• Square, How the Orders API works
• Square, CreateOrder reference
• Square, CalculateOrder reference