> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fire.rest/llms.txt
> Use this file to discover all available pages before exploring further.
# Terminals
> Register the kiosks of every store from one screen, and decide what each device charges and who can unlock it.
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**.
***
## 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.
| Message | What happened | What you do |
| ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | --------------------------------------------- |
| **Kiosk registered** | Created in Fire and in the channel | Nothing |
| **The kiosk already existed in the channel and was adopted** | It was already on the other side — Fire took it over instead of duplicating it. From now on Fire is in charge | Nothing |
| ⚠️ **Registered in Fire, but the channel did not accept it yet** | The registration is **half-done** | Find the card in the list and press **Retry** |
**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](/en/manuals/payments/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.
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
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.
Each method carries a caption saying where its current position comes from:
| Caption | What it means |
| -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| *Not offered on kiosks in this store.* | The store doesn't offer it. The switch is disabled here — turning it on would enable it on **every** kiosk in the store, and that's a decision for [store configuration](/en/manuals/payments/store-configuration) |
| *Follows the store: charging.* | Inheriting, and charging |
| *Follows the store: paused.* | Inheriting, and paused at store level |
| *Set on this terminal: charging.* | Override — it charges here even though the store has it paused |
| *Set on this terminal: not charging.* | Override — this machine doesn't charge it, the others still do |
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.
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](/en/manuals/pos/linking) for that flow.
POS registers do show up on this list, and you can administer them from here — see [Terminal administration](/en/manuals/pos/terminal-admin) for suspending, reactivating and revoking.
The older [Kiosk → Linking](/en/manuals/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](/en/manuals/payments/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.
| | K-01 | K-02 | K-03 |
| -------------------------------------------- | --------------------------- | ----------------------------------------- | --------------------------- |
| **Before** | Follows the store: charging | Follows the store: charging | Follows the store: charging |
| Switch off Datafast on K-02 | Follows the store: charging | **Set on this terminal: not charging** | Follows the store: charging |
| The store pauses Datafast for an outage | Follows the store: paused | Set on this terminal: not charging | Follows the store: paused |
| The store resumes it | Follows the store: charging | **Set on this terminal: not charging** ⚠️ | Follows the store: charging |
| Pinpad repaired → **Follow the store again** | Follows the store: charging | Follows the store: charging | Follows the store: charging |
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
| Term | What it means |
| ---------------- | ------------------------------------------------------------------------------------------ |
| **Device ID** | The identifier the kiosk shows on its QR screen. What Fire uses to find it in the channel. |
| **Adoption** | The kiosk already existed in the channel and Fire took it over instead of duplicating it. |
| **Provisioning** | Creating or adopting the kiosk on the channel side. |
| **Sync** | Pushing what's configured in Fire out to the device. |
| **Override** | A value set on one terminal that stops it inheriting from the store. |
| **Pairing** | The POS flow: a 6-digit code entered on the device. Kiosks don't use it. |
***
## 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](/en/manuals/payments/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.