Skip to main content
GET
Returns the payment configuration Fire holds for the vendor bound to your API key, resolved store by store: which methods each one offers, where each of them charges, and with which values. Every entry is self-contained — there is no catalog to join against. With no filter it returns every store of the vendor, paginated. With storeId or storeCode, a single one.
The response includes configuration values, including the ones flagged as secret (merchant keys, card-reader credentials). Treat this response as sensitive material: do not log it, do not cache it in a browser, and do not forward it to third parties.
This is v2. v1 returns country → vendor → methods with an enabled flag and stays available, with no sunset date. v2 changes where the data comes from and adds the store, channel, fulfillment and terminal levels.

Authentication

string
required
Your Fire API key with the payment-methods:read scope. The key must be vendor-scoped (account + vendor binding) — keys without a vendorId are rejected with 403. Account and vendor are resolved from the key; they are not accepted as query params.

Parameters

string
The store’s UUID in Fire. Mutually exclusive with storeCode: sending both returns 400.
string
The store’s external code (EXTERNAL CODE in the backoffice). This is the identifier you most likely already hold in your own store master. It is unambiguous because the API key pins the vendor.
string
Narrows availability to one channel (for example KIOSK). Compared uppercased. Stores left with no combination for that channel still appear, with no methods.
integer
default:"1"
Page of stores.
integer
default:"20"
Stores per page. Maximum 100.

Request

Response

boolean
Always true on a 200.
object

How to read the response

To decide whether to show a method in a store, look at charging. It is true when the method is active on the account and charges in at least one combination of that store. To know in which channel and fulfillment it charges, look at availability. An entry with enabled: false means “configured here, but switched off right now” — the provider is down, say. That is different from not appearing at all: what does not appear is not offered in that store. Collapsing the two costs you later: drop the paused entries and, the day the method is resumed, your side reads it as a combination nobody ever set up and reconfigures what was already there. Before attempting a charge, look at missingRequiredKeys. If it carries anything, mandatory data is missing and the charge will fail on the provider’s side. devices is almost always empty. It shows up when one terminal has an exception — a kiosk’s card reader broke and only that unit was switched off, leaving the rest of the store charging. If your integration does not distinguish terminals you can ignore it: the store level is the right answer for a sales channel.

Notes

  • Identify methods by methodId, never by code. A code is unique only within a country, and a vendor with stores in two countries can define the same code twice, with different ids.
  • fulfillmentCode is returned exactly as stored, without normalizing against the global catalog.
  • Methods with active: false are returned anyway, so you can render them as “unavailable” or hide them — your call.
  • Asking for a store that does not belong to your key’s vendor returns 404, not 403.

Payment method configuration (v1)

The previous version, without store levels. Still available.

Channels configuration

Which channels and fulfillments your vendor has enabled.