Skip to main content
Registering a freshly installed kiosk used to mean going to another system, creating a restaurant there, coming back, and hoping the two ends matched. This screen replaces all of that: you register the kiosk in Fire with the ID on its QR screen, and Fire creates it in the channel — or adopts it if it was already there. It’s also the account’s master list. Every terminal in every store, POS and kiosk, in one place with a filter by store. Navigate to Operation → Terminals.
Terminal list with store filter and status tabs

​
The short version

1. Registering a kiosk needs two things: the store and the device ID. No restaurant template, no payment methods. A kiosk is born with nothing configured, on purpose.2. A registration can half-succeed. “Registered in Fire, but the channel did not accept it yet” is a warning, not an error, and the dialog closes anyway. That kiosk doesn’t charge until someone presses Retry.3. Payment methods and the admin password both work the same way: the store sets the default, a terminal can override it, and there’s always a way back to inheriting.

​
The simple path

Someone just plugged a kiosk in at a store and you want it running:
  1. New terminal.
  2. Terminal type: KIOSK.
  3. Store: pick it from the list.
  4. Device ID: type it, or press the QR button and scan the code the kiosk is showing.
  5. Register.
Read the message that appears. If it says Kiosk registered or that it was adopted, you’re done — the device is on the list and ready to be configured. If it’s yellow, keep reading: it isn’t finished.
The kiosk shows its QR and its Device ID on its own home screen. You don’t have to write anything down: the scanner reads it.

​
The three ways a registration ends

This is the most important part of the screen, because two of the three look like success.
Register a terminal dialog with the kiosk fields
The third one closes the dialog just like the other two. The kiosk appears on the list, looks normal, and is not operating: the channel never got it. Nothing retries on its own. If you close the screen without reading the message, you find out when the store calls to say the kiosk won’t charge.
Adoption is not an error either — it’s the expected path for a device that was already installed. Fire doesn’t create a second one; it takes the existing one and starts driving it.

​
Why it doesn’t ask for a template or payment methods

Because registration happens in the field, often by whoever is physically installing the machine, and every extra question is a chance to get it wrong. A kiosk is always born with no payment methods. That’s deliberate: if the form pre-filled them with whatever the store had at that moment, two identical registrations done a week apart would produce two different kiosks, and nobody would know why. What it charges is decided afterwards, from this same screen or from store configuration. The restaurant template isn’t required either. If it exists in the channel, Fire uses it. If it doesn’t, Fire builds the minimum from the store’s own data and moves on. Stopping there would mean going off to create a restaurant in another system in order to register a machine that’s already installed and plugged in. There’s one thing the store does need to have loaded: country and city. Without them the channel can’t create the kiosk, and the registration comes back with the yellow message.

​
Sync failed and Retry

The card only speaks up when something is wrong. There’s no green banner saying everything is fine — that would turn the list into noise and the one card that needs attention would get lost in it.
Terminal card showing the sync failure warning and the Retry button
An amber panel with Sync failed — or Not synced — means Fire and the channel disagree, and the last error is printed underneath. Retry does two things in order: it re-provisions the kiosk in the channel (creating it, or adopting it, if it wasn’t there) and then pushes the payment methods and the password. Common causes, in the order worth checking:
  1. The store has no country or city. Fix the store and retry.
  2. The channel was unreachable when the change was saved. Retrying is usually enough.
  3. The kiosk doesn’t exist on the other side — someone deleted it there. The retry recreates it.
Nothing retries by itself. There’s no automatic retry and no bulk retry: it’s one button per card. A kiosk left in Sync failed keeps charging with its previous configuration for as long as nobody looks at it.

​
Inheritance and override: the pattern that runs the detail view

Open a terminal’s card — the ⋮ menu, then View details — and you’ll find two sections that behave identically. In both, the store sets the default and every kiosk in it inherits. When one machine needs to differ, you set the value on that terminal and it becomes an override that only applies there. And in both there’s an explicit way back to inheriting, because an override you can’t undo is a trap. Learn it once, and both sections read themselves.

​
Admin password

Kiosk detail with the admin password and payment methods sections
This is what unlocks the admin screen on the device itself. The line at the top tells you where the kiosk currently stands: Inherited from the store, Set for this terminal only, or Not set — this kiosk has no admin password in amber. To change it, type it under New password and choose Applies to:
  • Every kiosk in this store — the default, and what you want almost always.
  • Only this terminal — creates the override.
Go back to the store one appears only when there’s an override, and removes it. The password is never displayed. You can see whether one is set, not what it is — putting a credential in an HTTP response would leave it in the browser history. It must be at least 6 characters; if it’s shorter, the error comes back from the server after you press Save password.
Clearing it doesn’t unlock a device that already has one. Fire simply stops imposing a password; it doesn’t take away the key a kiosk already received. To actually change what the machine asks for, set a new one.

​
Payment methods

Same shape, applied to what the kiosk charges.
Payment method expanded with the terminal's own values
Each method carries a caption saying where its current position comes from: Flipping the switch creates the override for this device only. Follow the store again removes it and the method goes back to doing whatever the store does. The case this exists for: three kiosks in a store, one with a broken pinpad. You switch the card method off on that one and the other two keep charging. Before, that was a decision you could only make for the whole store. Expanding a method shows Values for this terminal: the fields the method declared at Terminal level — a pinpad IP, a device serial number. If it declares none, it says so.

​
POS registers aren’t created here

Choosing POS in the type selector replaces the form with a notice: POS registers use pairing. A POS is paired from the device itself with a 6-digit code, so it’s created from its own screen — Go to POS terminals takes you there.
Register dialog with POS selected showing the pairing notice
The two paths are genuinely different: a kiosk already carries its identity in the QR, so asking it to pair would be inventing a step that protects nothing. See POS → Linking for that flow. POS registers do show up on this list, and you can administer them from here — see Terminal administration for suspending, reactivating and revoking.
The older Kiosk → Linking guide describes registering kiosks from the other system, with a restaurant template and payment methods in the modal. It’s the previous flow. What this manual describes is the current one.

​
Recipes: how to handle real-world cases

  1. New terminal → type KIOSK.
  2. Pick the Store.
  3. Press the QR button and scan the code the kiosk is showing, or type the Device ID by hand.
  4. Leave Name empty unless you have a naming convention — Fire names it after the store.
  5. Register, and read the message.
If it came back yellow, go to the card and press Retry.
In this order:
  1. Is there an amber panel on its card? If so, Retry and read the error.
  2. Open the detail → Payment methods. Look at the captions: Not offered on kiosks in this store is a store problem, Set on this terminal: not charging is an override somebody left behind.
  3. If it says Follows the store: paused, the pause is at store level — fix it in store configuration.
  4. If it charges but fails against the provider, the method is probably missing a required value: look for the amber chip on the store screen.
  1. Open that terminal’s detail.
  2. Payment methods → switch the card method off.
  3. Check the caption now reads Set on this terminal: not charging.
The other kiosks in the store carry on charging. When the pinpad is repaired: Follow the store again, and it goes back to doing what the store does.
  1. Open the detail of any kiosk in that store.
  2. Admin password → type it under New password.
  3. Applies to: Every kiosk in this store.
  4. Save password.
Every kiosk in the store inherits it, including ones registered later. The ones with their own override keep theirs — to bring those back into line, open each and use Go back to the store one.
  1. Open the terminal’s detail → Payment methods.
  2. Expand the method with the chevron.
  3. Fill in Values for this terminal and Save values.
Only fields the method declared at Terminal level appear here. Account- and store-level ones aren’t editable from here on purpose: changing them from one device’s detail would affect the others without it being visible.
Use the store selector in the header. The tabs then split what’s left by status: Active, Suspended, Revoked, plus Deleted if you tick Show deleted.There’s no search box: the store filter and the tabs are the tools. The list is ordered newest first, so a device you just registered is at the top.

​
Three kiosks in one store, followed end to end

Laboratorio has K-01, K-02 and K-03. The store offers Cash and Datafast. K-02’s pinpad breaks. The row worth reading twice is the fourth. The override survives the store’s changes — that’s exactly what it’s for, and it’s also how a machine ends up not charging weeks after everyone forgot the pinpad was ever broken. An override is a decision that stays until someone undoes it.

​
Mistakes that cost money

Closing the registration dialog without reading the message. “Registered in Fire, but the channel did not accept it yet” is yellow, closes like a success, and leaves a kiosk that doesn’t charge.
Leaving an override in place after the reason for it is gone. The machine stops following the store for good. Weeks later a method is charging everywhere except on that one kiosk, and nothing on the store screen explains why. Use Follow the store again.
Ignoring a Sync failed card. There’s no automatic retry. That kiosk keeps operating with the configuration it had before the change — old prices of a payment method, an old password, a method that should no longer be offered.
Assuming clearing the password locks the device. It doesn’t. Fire stops imposing one; the kiosk keeps the key it already has. To change what it asks for, set a new password.

​
Glossary

​
Frequently asked questions

Look at its card. If there’s an amber panel, press Retry and read the error. The most common cause is the store missing a country or city — with those loaded, the retry goes through.
Fire won’t let you: it tells you which terminal is already using it. A device ID can’t be repeated within an account.
No. The switch in a terminal’s detail only creates an override for that device. To change what the whole store offers, use store configuration — which is what the link at the top of the section is for.
Because doing it from here would enable it on every kiosk in the store, and that decision belongs on the store screen. Enable it there and the kiosk inherits it.
No. You can see whether it’s set, inherited or absent, never the value. If nobody remembers it, set a new one.
No. That section only appears for kiosks. The POS still receives its payment methods through its own snapshot.

​
What’s coming

Things this screen does not do today:
  • No automatic sync retry, and no bulk retry: it’s one Retry per card.
  • No POS/kiosk type filter. The filter is by store, and the tabs by status.
  • No search and no pagination. Everything in the account — or the selected store — is loaded at once.
  • Manual register close is visible but disabled, marked Coming soon.
  • POS registers aren’t created here: they’re paired from the device.
  • A registration that half-succeeds isn’t rolled back. The kiosk stays in Fire waiting for a retry, on purpose: undoing it would mean redoing the whole registration over a timeout.