Multiple Stores, One Crypto Gateway: 2026 Limits

You launched a second brand, the checkout works, and then the first payout lands: one balance, one transaction list, two businesses you now have to separate in a spreadsheet. The question nobody answers before you integrate is whether a crypto payment gateway can run multiple stores at all, or whether "multiple stores" just means you remembered to label your API keys.

It matters more than it sounds. The gateway's object model decides whether your refunds come out of the right brand's float, whether an accountant can reconcile a month without you, and whether a compliance hold on one shop freezes the other. We read the reference documentation for seven gateways on 14 October 2026 — BTCPay Server, Cryptomus, CoinGate, BlockBee, Apirone, OxaPay and Plisio — looking for one thing: what is the smallest unit the provider will let you separate, and which parts stay joined whatever you do.

What a store means inside a crypto payment gateway

Four different answers exist, and the word "store" appears in none of the documentation for three of them. A gateway either gives you a first-class store object you create and configure, a merchant or wallet object that behaves like one if you squint, a credential you can name and nothing more, or a single global configuration form.

That distinction is the whole article, because it predicts exactly which of your problems the gateway will solve. A store object carries its own settings, its own keys and its own reporting. A credential carries a name. Here is where the seven landed.

Gateway	What you can create	Credentials per brand	Payout wallet per brand	Stays shared
BTCPay Server	Stores, no documented limit	Yes, keys scoped to a store	Yes, a wallet per store	The server instance, plugins, server-wide settings
Apirone	Wallets, one POST each	Yes, wallet id + transfer key	Yes, up to 255 destinations	Nothing documented
Cryptomus	Merchants, created in the dashboard	Yes, a payment key per merchant	No, one account-level payout key	Payouts, 2FA, business verification
CoinGate	API Apps	Yes, one token per app	No	Ledger balances, verification, settlement
BlockBee	API keys, plus per-call parameters	Yes, named keys	Yes, passed per request	The account and its KYC tier
OxaPay	Named keys, split by service	Yes, by name only	No, one payout key per account	Everything but the key name
Plisio	One shop configuration	No	No	Everything

Read the right-hand column first. It is the list of things you will still be doing by hand in six months.

BTCPay Server is the only one with real stores

BTCPay is self-hosted, which is why it can afford to be generous: there is no provider absorbing the cost of your account sprawl. Its FAQ states the limit plainly — "There's no limit on a number of stores you can create in BTCPay" — and each store keeps its own settings, down to which exchange-rate provider it uses, because "each store may use different settings".

The non-obvious part is wallets. Most people assume two stores need two wallets, and buy a second hardware device for a second brand. BTCPay's wallet FAQ says you can "create 2 separate stores on BTCpay Server under the same instance with the same xpub", and that it "will do address rotation correctly and never re-use between the stores" — with one hard condition set in the same breath: "This has to be done on the same instance." Two servers deriving from one extended public key will hand the same address to two different customers.

Keys follow the same pattern. BTCPay's own API example tells you to use a token that holds btcpay.store.cancreateinvoice, "scoped to the selected store when possible" — so a leaked key from brand A cannot invoice for brand B. That is the design every hosted gateway below approximates and none of them quite reaches.

Cryptomus separates the inbound leg, not the payout

Cryptomus comes closest among the custodial providers. Its key-generation guide starts with "Create Merchant or open Settings tab in merchant", so a merchant is an object you make rather than an identity you are issued, and the payment key belongs to it. Two brands, two merchants, two payment keys: clean enough.

Then the money moves and the model collapses into one. The same page is explicit that "you need to release a different API key for accepting payment and making payouts", and that payout key is generated in the account's Business settings behind two-factor authentication — not inside a merchant. One payout credential for the whole account, whatever you built upstream.

So the practical shape at Cryptomus is: separate what customers touch, and keep one treasury with your own ledger on top. Fees and custody terms are in our Cryptomus review.

CoinGate gives you apps, not accounts

CoinGate's unit is the API App. Its callbacks reference says that "by creating new API App you can choose in which format you want to receive callbacks", and points you at Merchant » API » Apps » Edit to change one later. Per-brand tokens, per-brand callback format, per-brand integration: all available, all free.

What does not separate is the balance. The ledger reference states that accounts hold your funds "with one account per currency and account type". Two brands invoicing in euros share one euro ledger account, so attribution has to come from your own order_id and the callbacks you store, never from a CoinGate balance screen.

One more trap that catches people building a second brand against a sandbox: Live and Sandbox are "entirely separate environments", and "you need to create separate accounts for each", with separate credentials. A test token that works in staging will not work in production, by design. CoinGate's fees, licensing and verification requirements are in the CoinGate review.

BlockBee and Apirone put the brand in the request

The forwarding processors invert the question. There is no store to configure because the parameters that would define one travel with every API call, which makes them the most flexible of the seven and the easiest to get wrong.

At BlockBee the payout wallet is a per-call field, so brand A's invoices can forward to one wallet and brand B's to another without touching the dashboard. It also splits a single payment across wallets with a compact syntax — percentage_1@address_1|percentage_2@address_2, documented with the example 0.5@ADDRESS_1|0.5@ADDRESS_2. That is how a shared brand pays an affiliate or a partner out of the incoming payment rather than afterwards.

The handle you must not share is the callback URL. BlockBee's reference warns that "the callback URL should be unique" because "the same callback URL will return the same address_in, meaning it works similarly to an ID", and tells you to make it unique with query parameters such as ?user_id=1234. Point two brands at one webhook route and they will share one payment address; ask for a different coin on that route and you get a 400 reading "Non multi_token address already created for another token".

Separation handle	BlockBee	Apirone
Object you create per brand	None — an API key and per-call parameters	A wallet, one POST, currency the only required field
Credential	Key generated in the dashboard	Wallet id plus a transfer key per wallet
Payout destination	Passed with each create call	destinations array, up to 255 addresses
Splitting	0.5@ADDRESS_1|0.5@ADDRESS_2	Fixed minor units or percentages
Callback	Per call, and it keys the address	Per wallet and per address, under 1,024 characters

Apirone is the quiet winner for a multi-brand operator. A wallet is created by a single POST to its v2 wallets endpoint, it is "a container of addresses, which are generated as many as need", and it comes back with its own identifier and transfer key. Three brands, three wallets, three keys, three destination sets — and no shared balance screen to untangle. The custody trade-offs are in our Apirone review and in Web3 Payment Gateways.

OxaPay and Plisio: named keys and one shop form

OxaPay splits credentials by job rather than by brand. You generate a Merchant API key for payments, a Payout API key for withdrawals and a General API key for swaps, and the docs invite you to give the merchant key "a meaningful name for identification purposes". A name is useful for an audit trail; it is not a boundary, and the same page notes the key "grants access to your OxaPay account for processing payments".

The payout side is where OxaPay earns a point the store-based gateways do not. It lets you "specify Allowed IPs for transfers", restricting payout requests to named addresses — so even one shared payout key can be pinned to one server. If your brands run on separate infrastructure, that is a real control. Fees and custody terms sit in the OxaPay review.

Plisio is the honest floor of the set. Its getting-started documentation describes one shop form — one Status URL for callbacks, one Success URL, one Failed URL, one switch to disable withdrawals via API — and states that the secret key "will be used with all API calls". Nothing in the reference describes a second shop, a second key or a per-shop payout. Run two brands through it and you are running them through one.

What a second account on a crypto payment gateway really costs

"Just open two accounts" is the standard forum answer, and it does buy genuine isolation: two balances, two keys, two dashboards, two payout schedules. It also duplicates every piece of friction you only wanted to go through once.

Start with verification. BlockBee's tiers are published and they are per account: no KYC up to $1,000 of volume, partial KYC — "only ID verification" — up to $500,000, full KYC above that for unlimited volume. Two accounts means two onboarding tracks and two counters starting at zero.

What you duplicate	One account, several stores	Two accounts
Verification / KYB	Once	Twice, with each tier counted separately
Volume thresholds	Pooled, so tiers arrive sooner	Split, so each stays lower for longer
Payout minimums and network fees	One withdrawal, one fee	One per account, per currency
Reconciliation	Your own order ids	Clean, if you never mix the keys up
Blast radius of a hold	Both brands stop	One brand stops
Support history	One relationship	Two, neither of which knows the other

And one line of caution, because the table above makes it look like arbitrage: deliberately splitting one business across accounts to keep each under a verification threshold is the pattern compliance teams are built to spot, and it risks both accounts rather than neither. The honest reasons to run two are different entities, different jurisdictions, different risk profiles, or a sale you expect to carve out later. What a hold looks like when it arrives is in Crypto Gateway AML Holds 2026, and what the gateway checks in the first place is in Crypto Payment Screening 2026.

The five layers to check before you integrate

Separation is not one feature, it is five, and a gateway can give you the first two while sharing the last three. Ask in this order, because the cheap questions come first and the expensive ones are the ones nobody asks.

1. Credential. Can brand A hold a key that cannot invoice for brand B? BTCPay scopes it to a store; Cryptomus and CoinGate issue one per merchant or app; OxaPay lets you name one. 2. Callback. Is the webhook per brand, and does the gateway treat that URL as an identifier? At BlockBee it is the identifier. 3. Payout. Does each brand forward to its own wallet, or does one balance pay everything? This is the layer that usually fails.

4. Ledger and reporting. Can you pull a month for one brand without filtering by hand? One ledger account per currency means no. 5. People. Can a bookkeeper see one brand only? BTCPay is the only one of the seven whose documentation puts permissions and stores in the same sentence; everywhere else, access is account-wide.

Which structure fits which business

Two brands sharing one entity, under roughly $500,000 a year, with the same risk profile: one account, one key per brand, your own ledger. The gateway's separation is cosmetic at this size and the duplicated onboarding is not worth it. Use the order-id discipline above and move on.

Separate legal entities, separate jurisdictions, or an adult, gaming or high-risk brand next to a mainstream one: separate accounts, every time. A single hold should not be able to take the clean business offline with the risky one, and that is exactly what a shared account guarantees. No-KYC crypto payment gateways is the starting list if one brand cannot complete verification.

Five brands or more, or any plan to sell one of them: self-host. BTCPay's unlimited stores, store-scoped keys and one-instance xpub rule are the only arrangement in this set that scales without a spreadsheet, and the carve-out is a wallet rather than a migration. The hosting cost and the operational work are real — we priced both in the BTCPay Server review.

FAQ

Can one crypto payment gateway account handle multiple stores?

Partly, and only on the inbound leg at most providers. Of the seven we read on 14 October 2026, BTCPay Server is the only one with a documented store object and no stated limit on how many you create. Cryptomus lets you create merchants and issue a payment key to each, CoinGate lets you create API Apps, and the rest give you a credential you can name. None of the hosted six documents a per-store balance.

Do crypto payment gateways have sub-accounts?

Not under that name in any of the seven reference sets we read. The closest equivalents are a BTCPay store, a Cryptomus merchant, a CoinGate API App and an Apirone wallet. If a provider's sales page promises sub-accounts, ask which of the five layers — credential, callback, payout, ledger, users — it actually separates, because the word is used for all five.

Should I use a separate API key for each website?

Yes, wherever the provider allows it, and it is nearly free. A per-site key limits what a leak or a compromised plugin can do, it makes rotation possible without taking every brand offline, and it gives you a second attribution field in your own logs. Check the rotation cost first: at Cryptomus a new payout key blocks withdrawals for 24 hours.

Can two stores share one wallet or xpub?

On BTCPay Server, yes, with a condition. Its wallet FAQ says two stores on the same instance can use the same xpub and that it "will do address rotation correctly and never re-use between the stores" — but "this has to be done on the same instance". Two servers deriving from one key have no shared view of what has been issued, so they can hand one address to two customers.

Is it against the rules to open two gateway accounts for one business?

None of the documentation we read on 14 October 2026 forbids it or permits it; BlockBee and OxaPay are silent in both directions. Get it in writing from support before you build on it. Separate entities, jurisdictions or risk profiles are the defensible reasons; splitting volume to stay under a verification threshold is not, and it puts both accounts at risk.

How do I keep two brands apart if the gateway pools the balance?

Do the attribution yourself. Put a brand key in every order id, register a distinct callback URL per brand, and store the payment address plus the raw webhook against the order. Then reconcile from your own records and treat the gateway balance as a single treasury account. This is the only method that works at all seven providers.

Which crypto payment gateway is best for multiple stores in 2026?

BTCPay Server if you can self-host: unlimited stores, store-scoped API keys and per-store settings. Apirone if you want hosted-style simplicity with real separation, because a wallet is one POST and carries its own transfer key and destination list. Cryptomus or CoinGate if you need their coverage and will accept one treasury with your own ledger on top.

Sources

Primary documentation, read 14 October 2026:

• BTCPay Server — Stores FAQ (store limit, per-store settings)
• BTCPay Server — Wallet FAQ (two stores, one xpub, same instance; gap limit)
• BTCPay Server — API examples (store-scoped permissions)
• Cryptomus — Getting API keys (merchant creation, payment vs payout key, 24-hour block)
• CoinGate — API callbacks (API Apps, per-app callback format)
• CoinGate — List ledger accounts (one account per currency and account type)
• CoinGate — Environments (separate sandbox account)
• BlockBee — Create payment address (callback URL as identifier, payout splitting)
• BlockBee — KYC tiers ($1,000 and $500,000 thresholds)
• Apirone — Wallet API (wallet creation, transfer key, 255 destinations)
• OxaPay — Payout API (key naming, Allowed IPs for transfers)
• Plisio — Setting shop (single shop form, account-wide secret key)