Skip to main content
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.
Store, channel and fulfillment matrix with payment method chips

​
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. 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.
Method chips in their three states
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.
Method panel with account, store and terminal sections
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. 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 — 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:
Bulk action bar with combinations selected
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.
Add payment methods dialog
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 payment methods dialog
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: 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, 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: 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

​
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 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.