> ## 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.
# Store configuration
> Decide where each payment method actually charges, and load the data it needs — without going store by store.
The same payment method isn't charged everywhere. Cash works at the counter and not on the app. The card processor is on the kiosks but not on delivery. A store that just opened doesn't have its bank code loaded yet.
A chain with 40 stores, 3 channels and 3 fulfillments has **360 combinations**. Holding that one by one doesn't scale, and a combination that's wrong isn't a small detail: it's a customer who reaches the payment screen and can't pay.
This screen is the map of all of them. Navigate to **Operation → Store configuration**.
***
## The short version
**1. Two things live here, and they don't work the same way.** *Where* a method charges is decided per store, channel **and fulfillment**. *What data* it uses is loaded per account, store or terminal — with no fulfillment involved.
**2. Pausing is not removing.** A paused method keeps its configuration and can come back with one click. A removed one stops being offered.
**3. The ⋮ menu on a row reaches the whole channel**, not just the row you're looking at. For a single row, use the checkboxes.
***
## The simple path
You have a new method and you want it charging in one store:
1. Find the store in the list — search by name or code.
2. Tick the checkbox on the **store row**: that selects all of its combinations.
3. **Add methods** in the blue bar.
4. Check the method and confirm.
If the method needs no data, it's charging already. If it does, it shows up in amber as **Setup required** and the next section tells you how to fill it in.
If your methods are cash-only and card-at-the-counter with no credentials, this is the whole manual. The rest is for methods that need data.
***
## The idea to take away: availability and configuration are separate
This is the one thing worth understanding, because everything else follows from it.
| | Availability | Configuration |
| -------------------- | --------------------------------- | ------------------------------------------ |
| **What it answers** | Where does this method charge? | What data does it use to charge? |
| **Broken down by** | Store × channel × **fulfillment** | Account / store / **terminal** |
| **Where you set it** | The chips and the bulk bar | The panel that opens when you click a chip |
The consequence is what surprises people: loading Datafast's credentials from the **Kiosk · Dine-In** row also leaves **Kiosk · Takeaway** ready. It's the same pinpad charging — the fulfillment doesn't change the machine. The panel itself says so above the form:
> *Availability is per fulfillment, but this configuration is not: what you save here applies to Kiosk in every fulfillment, not only Dine-In.*
So you can enable the method on dine-in and not on takeaway, and still enter its data once.
***
## Reading the chips
Each combination shows its methods as chips. The color is the whole status at a glance.
| Chip | Means | What happens when someone pays |
| ------------------------------ | ------------------------------------------------ | -------------------------------------------------------------------------------------------------- |
| **Green**, the method's name | Charging | It's offered and it works |
| **Grey**, with a pause icon | **Paused** — switched off on purpose | It's **not** offered as payable, but the device still knows it exists. Its configuration is intact |
| **Amber**, with a warning icon | **Setup required** — a required field is missing | It's still offered. The charge fails against the provider instead of the method disappearing |
| *Not shown* | Not offered there | The device doesn't even know about it |
**Amber does not stop the charge.** *Setup required* is a warning on this screen, not a block. The method reaches the device with incomplete data and fails at the counter, in front of a customer. It's the state you should be actively hunting for, not the one you can leave for later.
A chip for a method with per-terminal fields also shows how many devices are ready: **2/3 terminals**. One missing means one kiosk that won't charge while the other two do.
### The row's health
Above the chips, each row carries a pill summarizing it — and it's the same thing the **Availability** filter searches by:
* **Ready to charge** — every method is fine.
* **Setup required** — at least one is missing data.
* **No payment methods** — nothing offered here. Nobody can pay.
A row where **everything is paused** shows as *Ready to charge*: nothing is missing data. It's technically true and operationally misleading — if a store isn't charging and you can't work out why, look at the chips' color, not the pill.
***
## Loading a method's data
Click a chip and the panel opens with the fields the method declared, grouped by the level at which each is filled in.
| Section | What it asks for | Reaches |
| -------------------------- | ----------------------------------------------------- | -------------------------- |
| **Account configuration** | Shared across the whole account | Every store, every channel |
| **Store configuration** | Shared by every channel and fulfillment of this store | That store |
| **Terminal configuration** | One row per terminal in this channel | Each device on its own |
Required fields carry an asterisk and, next to each section, a mark tells you whether it's complete: a green check, or an amber triangle when something is missing. Fields declared as **Secret** are typed hidden, the way a password field works.
**Save changes** saves it. You can save incomplete — the combination stays in *Setup required* and nothing stops you.
**Saved isn't the same as synced.** If a kiosk was offline, instead of the confirmation you get *"Saved, but these kiosks did not get the change: … Retry from Terminals."* Fire kept your change; that device didn't. It keeps charging with the previous configuration until someone presses **Retry** on its card in [Terminals](/en/manuals/backoffice/terminals). This warning is not an error message you can dismiss.
The panel footer also has **Open payment method**, which takes you to the [method's editor](/en/manuals/payments/payment-methods) — useful when you notice mid-load that a field is declared at the wrong level.
***
## Working in bulk
Nobody configures 360 combinations one at a time. There are four ways to say *which* ones you mean:
| How | What it selects |
| --------------------------- | ------------------------------------ |
| Checkbox on a **child row** | That combination only |
| Checkbox on a **store row** | Every combination in that store |
| Checkbox in the **header** | Every filtered result |
| The **⋮** menu on a row | **The whole channel** for that store |
With something selected, the blue bar offers **Add methods**, **Resume**, **Pause** and **Remove methods**.
**The ⋮ menu reaches more rows than the one you're on.** Using it on *Kiosk · Dine-In* applies to **every fulfillment of Kiosk** in that store. It's deliberate — the pinpad's data doesn't depend on whether the order is eaten in or taken away — but it does mean you switch off more than you can see. When you want exactly one row, use its checkbox.
### Each action only offers what it can act on
The dialog doesn't list your whole catalog: it lists the methods the action can actually change in what you selected.
| Action | Lists | If it's empty it says |
| ------------------ | --------------------------------------------------------- | --------------------------------------- |
| **Add methods** | What isn't yet enabled in *all* the selected combinations | *Every method is already offered here.* |
| **Pause** | What's currently charging | *No methods are charging here.* |
| **Resume** | What's paused | *No methods are paused here.* |
| **Remove methods** | Everything that exists there | *No methods are offered here.* |
An empty dialog is information: it's telling you there's nothing to do, not that something failed.
### Pause or remove
Both stop the charge. They are not the same thing.
**Pause** is the one for a provider that went down. The combination stays on the map in grey, the device still knows the method exists — it just can't be used today — and **Resume** brings it back with everything it had.
**Remove** takes the method out of that combination. The configuration you loaded at account, store and terminal level survives, but the combination itself is gone: to bring it back you use **Add methods** and check it's not left in amber.
***
## Recipes: how to handle real-world cases
1. Search for the store by name or code.
2. Tick the checkbox on the **store row** — that takes all of its combinations.
3. **Add methods** → check the method → confirm.
4. Look at the chip that appears. Green means done; amber means it needs data.
If it came out amber, click the chip and fill in what's marked with an asterisk.
1. Filter **Payment method** by the affected one.
2. Tick the header checkbox: that selects every filtered result.
3. **Pause** → confirm.
Every combination goes grey and keeps its credentials. When the provider is back: same selection, **Resume**.
If the provider is down everywhere and for everyone, it's faster to uncheck **Active** on the [method itself](/en/manuals/payments/payment-methods): it pauses everything at once and reactivating brings back exactly what it switched off.
1. Find the store's row for the **Kiosk** channel.
2. Click the processor's chip.
3. Go to **Terminal configuration**: there's one row per kiosk in that channel.
4. Fill in the value for the new device and **Save changes**.
You don't need to repeat it for each fulfillment: what you save applies to the whole channel.
You can also do it from that kiosk's own card in [Terminals](/en/manuals/backoffice/terminals), under **Values for this terminal**. Same value, two doors.
This is the case where the ⋮ menu is the wrong tool, because it would take the whole channel.
1. Filter **Fulfillment** by *Delivery*.
2. Tick the checkboxes on the rows you want — or the header one, if it's every store.
3. **Remove methods** → check the method → confirm.
Dine-in rows aren't touched: they weren't selected.
1. Filter **Availability** by **Setup required**.
2. What's left is every combination that's offering a method it can't complete.
3. Work through them by clicking the amber chips.
Worth doing after opening stores or adding fields to a method: those are the two moments that generate amber in bulk.
There's no copy-from-another-store yet, so the fastest path is:
1. Search for the new store and expand it.
2. Tick the checkbox on the **store row**.
3. **Add methods** → check every method it should take → confirm.
4. Click each amber chip and fill in the **Store configuration** section. Account-level values are already there — they're shared.
You only load what's genuinely per-store. That's exactly what the levels are for.
***
## A store, followed end to end
*Laboratorio Ecuador*, Kiosk channel, two fulfillments, three methods:
| Combination | Datáfono Medianet | Datafast | DeUna |
| ---------------- | ----------------- | ------------------------ | -------- |
| Kiosk · Dine-In | 🟢 charging | 🟠 missing `merchant_id` | ⚪ paused |
| Kiosk · Takeaway | 🟢 charging | 🟠 missing `merchant_id` | ⚪ paused |
Row health for both: **Setup required**.
Someone clicks the Datafast chip, fills in `merchant_id` under **Account configuration** and saves. What happens:
* **Both rows go green at once.** The field was account-level: one value, and every store, channel and fulfillment offering Datafast is fixed with it.
* **DeUna stays grey.** Nobody asked it to come back — pausing was a decision, and nothing undoes decisions on its own.
* Had the missing field been `store_code` (store level), the fix would have reached that store's two rows and no other. Had it been `pinpad_ip` (terminal level), it would have fixed one kiosk.
**The level of the field that's missing is what tells you how much a single fix is worth.**
***
## Mistakes that cost money
**Using Remove when you meant Pause.** Remove takes the combination off the map; the device stops knowing the method exists. Bringing it back means adding it again and rechecking it doesn't come back amber. For a temporary outage, **Pause**.
**Acting through the ⋮ menu thinking it's one row.** It reaches the whole channel for that store. If you only meant *Dine-In*, you also switched off *Takeaway*, *Delivery*, and everything else that channel has.
**Leaving an amber chip for later.** *Setup required* doesn't stop the charge: it lets it through and it fails at the counter. It's the only state where the customer finds out before you do.
**Reading "Saved, but these kiosks did not get the change" as a confirmation.** It's yellow for a reason. Those devices keep charging with the previous configuration until someone presses **Retry** on the terminal.
**Trusting the green pill on a row where everything is paused.** *Ready to charge* means "nothing is missing data", not "money is coming in". A row with every method grey isn't charging anything.
***
## Glossary
| Term | What it means |
| ------------------- | -------------------------------------------------------------------------- |
| **Combination** | One store + one channel + one fulfillment. Each one is a row. |
| **Availability** | Whether a method is offered in a combination. |
| **Configuration** | The values a method uses to charge. Loaded per account, store or terminal. |
| **Paused** | Offered but switched off on purpose. Keeps its configuration. |
| **Setup required** | Offered but missing a required field. Does not stop the charge. |
| **Ready to charge** | The row has no methods missing data. |
| **Scope** | The set of combinations a bulk action applies to. |
***
## Frequently asked questions
Because the action can't do anything with it there. **Pause** only lists what's charging, **Resume** only what's paused, **Add methods** only what isn't already in *all* the selected combinations. An empty dialog means there's nothing to do.
No. Configuration isn't per fulfillment. What you save applies to that channel in every one of its fulfillments — and if the field is account-level, to every store as well.
Three usual causes: no vendor selected in the header (with no vendor there are no channels, and with no channels there are no rows), an active filter — check **Availability** and **Payment method** — or the account genuinely has no active methods, in which case there's an amber banner at the top telling you so.
Scope. Pausing here affects the combinations you selected. Deactivating the method in [Payment methods](/en/manuals/payments/payment-methods) affects every store at once — and reactivating restores only what the deactivation switched off, leaving anything paused by hand as it was.
Yes, and that's the point of the warning. It travels with incomplete data. What breaks is the charge against the provider, not the display of the method.
Not yet. Today this screen syncs to **kiosks**. The POS still gets its payment methods through its own snapshot.
***
## What's coming
Things this screen does **not** do today:
* **It doesn't copy configuration from one store to another.** A new store is set up by selecting it and adding the methods.
* **It doesn't stop you saving an incomplete configuration.** *Setup required* is a warning, never a block.
* **It doesn't mask stored secrets.** A field marked as *Secret* is typed hidden; treat what you put in there accordingly.
* **It doesn't sync to the POS**, only to kiosks.
* **It doesn't paginate.** Every combination is rendered in one table; collapsing by store is the relief valve.
* **It doesn't search by channel or method**, only by store name or code. For those, use the filters.