Guide

Crypto Gateway API Key Security 2026: We Checked 9

Q: Can you restrict a crypto payment gateway API key to one permission?

On one of the nine gateways read on 16 October 2026. BTCPay Server publishes 48 permission strings and lets you issue a key carrying only the ones you choose, narrowed to a single store with a colon and the store ID. The eight hosted gateways separate by key type at best, and CoinGate, Plisio and Apirone document no scoping at all.

Q: Do crypto payment gateways support IP whitelisting?

Some do, for payouts only. OpenNode attaches an allowlist to a withdrawal API key, OxaPay offers Allowed IPs on its Payout key, and NOWPayments has an account-level IP whitelist. At OpenNode and OxaPay the list is set when the key is generated and cannot be added later, so plan a static egress IP first. The other six do not document a per-key allowlist.

Q: How often should I rotate a crypto gateway API key?

BlockBee is the only provider in this set that gives guidance, and it says to rotate keys periodically without naming an interval. The more useful question is whether you can rotate at all: the cost ranges from a redeploy to a 24-hour payout freeze to an undocumented support ticket. Rotate on events you can see, such as a contractor leaving or a key appearing in a log.

We read nine crypto gateway API key policies in October 2026. Real permission scopes exist on one. Replacing a leaked payout key costs a day at another.

Jennifer McNallyUpdated October 16, 202613 min read

Key Takeaways

Crypto gateway API key security comes down to one question: what can this string do if it leaks? Only one of the nine gateways we read answers it with real permission scopes — BTCPay Server, which documents 48 permission strings and lets you pin any of them to one store ID. The eight hosted gateways offer one to three key types.
Rotating a leaked payout credential costs Cryptomus merchants a day. Its own instructions say "withdrawals will be temporarily blocked for 24 hour after generate new payout API key".
BlockBee's payout key has a key behind it. A V2 key ships with a Recovery Key "required to regenerate the API key if you lose it"; lose both and "your Self-Custodial Wallet funds become permanently inaccessible".
OpenNode's IP allowlist cannot be retrofitted. It "must be added to the withdrawal API key when it is first generated"; to add one later, "you must make a new withdrawal API key".
Three of the nine document no way to retire a credential at all. CoinGate, Plisio and Apirone each describe how to get a key and never how to replace one. Plisio is blunt about the blast radius: "This secret key will be used with all API calls."

Last checked: October 2026. Every key type, permission string, limit and quoted phrase below was read from the provider's own documentation on 16 October 2026 and is linked under Sources. Where a provider documents nothing we say so rather than guess — a silence in a reference page is not a control.

The string in your environment file can move your money. That is the whole of crypto gateway API key security in one sentence, and almost nobody selling you a gateway will say how much of your money, or how fast you could stop it. So we read nine providers' reference documentation on 16 October 2026 rather than their marketing copy.

The stakes are not theoretical. A payment key copied out of a staging container is an annoyance; a payout key is a withdrawal. Of the nine, exactly one documents a permission model fine enough to issue a key that creates an invoice and nothing else, three document no way to retire a credential once it exists, and one charges a full day of frozen payouts for replacing the key you were right to replace. Here is what a crypto payment gateway API key is worth to an attacker, provider by provider.

What a crypto gateway API key can actually do

Start with the only question that matters on a bad day: if this string leaks, what can the holder do? There are four answers in circulation, and the documentation tells you which one you bought.

A read key sees invoices and balances. A payment key creates invoices and addresses, which is mostly harmless because the money still lands in your wallet. A payout key sends funds out. An account key does all three, because it is your account in a header.

The finding is how rarely a provider lets you pick. OxaPay says plainly what you are holding: the merchant key "grants access to your OxaPay account for processing payments". Plisio is blunter — "This secret key will be used with all API calls." Neither sentence reads as a warning in context. Both are an accurate description of your exposure.

Neon-green-on-black table headed The only question that matters on a bad day. A read key sees invoices and balances, an information loss rather than a money loss; a payment key creates invoices and addresses, mostly harmless because the money still lands in your wallet; a payout key sends funds out, so a leaked payout key is a withdrawal rather than an annoyance; and an account key does all three at once, because it is your account in a header — Four kinds of key. The finding is how rarely a provider lets you pick which one you hold.

Nine crypto payment gateways, read 16 October 2026. "Not documented" means the provider's own reference pages do not mention it.
Gateway	Key types documented	Scope limits	IP allowlist	Documented way to replace a key
BTCPay Server	One key, 48 named permissions	Yes — per permission, pinnable to a store ID	Your server, your firewall	Delete the key, create another
OpenNode	Withdrawal keys, kept separate	By key purpose	Yes — withdrawal keys only, at creation only	A new key — no retrofit
Cryptomus	Payment key per merchant, account Payout key	By leg, not by permission	Not documented	Regenerate; withdrawals blocked 24 hours
BlockBee	V1 (receive), V2 (payouts, self-custody)	By generation — a V1 key cannot pay out	Not for keys; publishes its callback IPs	Revoke and regenerate; V2 needs its Recovery Key
OxaPay	Merchant, Payout, General	By service, not by permission	Payout key only, optional, at creation	Not documented
NOWPayments	Account credentials, payout permissions	Sub-account permissions, not scopes	Yes — plus an address whitelist	Not documented for keys
CoinGate	One Token per app	Not documented	Not documented	Not documented
Apirone	One transfer-key per wallet	Per wallet, by construction	Not documented	Not documented
Plisio	One SECRET_KEY	None — "used with all API calls"	Not documented	Not documented

Read the right-hand column twice. It is the one a merchant needs at 2am, and the emptiest.

Neon-green-on-black table of nine crypto payment gateways read on 16 October 2026. BTCPay Server has one key with 48 named permissions, scope per permission pinnable to a store ID, your own firewall for IP control, and replacement by deleting and re-creating. OpenNode keeps withdrawal keys separate, scoped by key purpose, with an allowlist on withdrawal keys set at creation only and no retrofit. Cryptomus has a payment key per merchant and an account payout key, scoped by leg, no documented allowlist, and regeneration that blocks withdrawals for 24 hours. BlockBee splits V1 receive from V2 payout keys so a V1 key cannot pay out, publishes callback IPs but no key allowlist, and needs the Recovery Key to regenerate V2. OxaPay has Merchant, Payout and General keys scoped by service, an optional payout-key allowlist at creation only, and no documented replacement. NOWPayments has account credentials and payout permissions, sub-account permissions rather than scopes, an IP allowlist plus an address whitelist, and no documented key replacement. CoinGate, Apirone and Plisio document none of it, Plisio with a single SECRET_KEY used with all API calls — The right-hand column is the one a merchant needs at 2am, and the emptiest.

BTCPay Server: 48 permissions, and you can pin one to a store

BTCPay Server is the outlier for a plain reason: it is software you run, so its permission model is a feature of the code rather than a tier of a plan. Its Greenfield API publishes all 48 permission strings in machine-readable form.

They break into families. Thirty-four are store-level, and the documentation gives the syntax for narrowing any of them to one store — append a colon and the store ID, as in btcpay.store.cancreateinvoice:6HSHAEU4iYWtjxtyRs9KyPjM9GAQp8kw2T9VWbGG1FnZ. Seven are administrator-only, five cover your own profile and notifications, one grants impersonation, and one is unrestricted.

BTCPay Server Greenfield permission families, counted from the API's published security scheme on 16 October 2026.
Family	Count	Example string	What a key holding only it can do
Store	34	`btcpay.store.cancreateinvoice`	Create an invoice — not read a wallet, not send. `cansigntransactions` is the one to withhold
Server / admin	7	`btcpay.server.canmodifyserversettings`	Manage the server, if its creator is an admin
User	5	`btcpay.user.canviewprofile`	Read your own profile
Impersonation	1	`btcpay.impersonation.canimpersonate`	Act as other users
Unrestricted	1	`unrestricted`	Everything the user can. The default to avoid

One line in that security scheme does more for your risk profile than any dashboard toggle in this comparison: "Note that API Keys only limits permission of a user and can never expand it." A key issued by a non-admin cannot become an admin key, whatever you type into it.

Neon-green-on-black table of BTCPay Server Greenfield permission families counted on 16 October 2026: 34 store permissions such as btcpay.store.cancreateinvoice, which let a key create an invoice but not read a wallet or send, with cansigntransactions the one to withhold; 7 server or admin permissions such as btcpay.server.canmodifyserversettings; 5 user permissions such as btcpay.user.canviewprofile; one impersonation permission, btcpay.impersonation.canimpersonate; and one unrestricted permission, the default to avoid — Forty-eight strings, and thirty-four of them can be narrowed to a single store ID.

Screenshot of the BTCPay Greenfield API v1 documentation, authentication section, stating that you can restrict the API key for one or multiple stores and for specific permissions and that on production you should limit the permissions to the actual endpoints you use — BTCPay's own Greenfield reference, captured 17 October 2026.

The practical setup is boring and effective. Give the storefront a key carrying btcpay.store.cancreateinvoice and btcpay.store.canviewinvoices, pinned to the one store it serves, and keep wallet and signing permissions out of anything facing the internet. Our BTCPay Server review covers the hosting cost of that trade.

Cryptomus: two-factor to get the key, 24 hours to replace it

Cryptomus splits credentials by leg rather than by permission, and it is the only provider here that makes two-factor authentication a precondition for holding a payout credential. Its instructions for generating one open with "Bind two-factor authentication if you haven't already done it": you cannot get the key that moves money until the account is protected.

That is the good half. The other half sits in the same numbered list, in parentheses: "Remember withdrawals will be temporarily blocked for 24 hour after generate new payout API key".

Why that sentence matters more than it looks. Rotation is an incident-response action: you do it the morning you find the credential in a public repository, or the day a contractor leaves. Cryptomus prices that at a day of frozen payouts, so the merchant who most needs to rotate is the one least able to afford it. The block is a sound anti-theft measure and a direct disincentive to good hygiene at once, and nothing in the documentation acknowledges the tension.

The payment leg is cleaner. A payment key belongs to a merchant you create inside the account, so a leaked storefront key exposes invoicing for one brand rather than withdrawals for all of them. The payout key comes from account-level Business settings, which is why regenerating it stops payouts everywhere — the same split we found from the other direction in running multiple stores through one gateway.

BlockBee: V1 receives, V2 pays, and there is a key behind the key

BlockBee has no permission list and no key-level IP allowlist, and still ends up with one of the better designs here, because it splits capability by key generation. A V1 key creates payment addresses and receives. Payouts and the self-custodial wallet need a V2 key, and the documentation says who should stay put: "Stay on V1 if: You only need to receive payments."

Never issue a V2 key and nothing in your stack can send funds — the outcome BTCPay reaches with a permission string, reached with a version number.

The catch is what a V2 key comes with: "A separate Recovery Key is generated when you create the V2 key. The Recovery Key is required to regenerate the API key if you lose it." Then the warning — "If you lose both, your Self-Custodial Wallet funds become permanently inaccessible."

Self-custody moves the failure mode, it does not remove it. BlockBee never holds V2 funds, so it cannot freeze them or lose them in an insolvency. It also cannot help you. The Recovery Key is not a convenience: it is the thing standing between a routine rotation and a permanent loss, and it belongs in the vault that holds your wallet seeds, not the environment file holding the key it recovers.

BlockBee is also the only provider here whose API reference carries an unprompted security section, and it says the right things: keep the key out of client-side code and public repositories, use HTTPS, "Rotate keys periodically", and revoke a compromised key from the API Keys page. Our BlockBee review has the fee and custody detail underneath it.

NOWPayments: the whitelist is the control, not the key

NOWPayments takes the opposite route: little about scoping a key, a great deal about constraining where money can go and where a request can come from. Both mechanisms were revised in 2026, which makes it the most actively maintained security surface in the comparison.

Two things are fenced. The destination, because a payout address must be whitelisted before funds can reach it. And the origin: "If a payout request comes from an IP address that is not yet approved, the account shows an error", with your current address pre-filled in the form.

NOWPayments whitelist mechanics, from the provider's own 2026 release notes.
Stage	What NOWPayments documents	Dated
Request an address	From the dashboard, manually or by CSV; it "goes directly through custody"	30 Jun 2026
Confirm it	"After the partner enters the 2FA code successfully, the address is automatically added to the whitelist"	30 Jun 2026
Code window	"The 2FA code is valid for 15 minutes"	30 Jun 2026
Unconfirmed	"If an address remains in REQUESTED status, it means the partner has not confirmed the request with the 2FA code"	30 Jun 2026
Remove an address	In-account; "confirmed with two-factor authentication"	30 Sep 2026
While removing	"While the address is pending removal, payouts can still be created to it"	30 Sep 2026
Wrong origin IP	An error for an IP "not yet approved"	30 Sep 2026

The row to plan around is the second-to-last. A removal is a request, not an event: the address stays payable until custody finishes processing it, so "I took that address off the whitelist" and "funds can no longer go there" are not the same statement on the day you need them to be. If you are retiring an address you no longer trust, the gap between the two is the window an attacker wants.

All of it is gated on the account's second factor, which puts NOWPayments and Cryptomus together as the two providers treating 2FA as part of the payment path rather than a login nicety. The NOWPayments review covers the fee and KYC side.

OxaPay and OpenNode: allowed IPs you can only set once

Two providers offer a per-key IP allowlist, both on the credential that sends money, both with the same structural flaw: the list is a creation-time decision.

OpenNode states it outright. "IP address whitelists must be added to the withdrawal API key when it is first generated", you are prompted for the address as part of the key request, and several are comma-separated. To add one to a key that lacks it, "you must make a new withdrawal API key". Enforcement runs both ways: with a list, "OpenNode will not authorize BTC transfer requests from other IP Addresses"; without one, "OpenNode will allow any remote IP to initiate a BTC transfer request".

OxaPay is the same shape, one step softer. It issues three key types by service — Merchant, Payout and General — and only the Payout key takes an allowlist: "Optionally, you can set the Allowed IPs for transfer in the provided field."

What a creation-time allowlist does to your infrastructure. It makes your egress IP a permanent dependency of your credential. Move hosts, add a region, or let a provider rotate your outbound address, and the fix is not an edit — it is a new key, a redeploy, and a window where one of the two is wrong. Budget a static egress address before you generate the key.

Note what an allowlist cannot do: it constrains a request's origin, not its content. A leaked key plus a compromised server inside the allowlist is an unprotected key. Good against credential theft, poor against intrusion.

CoinGate, Plisio and Apirone: one credential, no fence

Three of the nine publish nothing about scopes, allowlists or rotation, and each silence has a different shape.

CoinGate hands you a token and an Authorization header. Its API-authentication reference carries an updatedAt date of 10 June 2025 and covers one thing — "Provide generated Token to HTTP Authorization Header" — plus a note that sandbox credentials are separate. No permissions, no IP restrictions, no revocation path. Its support article on creating a key sits behind a bot wall we could not read, so this is what the developer documentation says, not proof the dashboard offers nothing.

Plisio is the clearest statement of maximum blast radius here, and it is not framed as a caveat: "This secret key will be used with all API calls." One key, every endpoint, passed as a query parameter in the documented examples — and query parameters land in access logs and proxy logs in a way headers do not.

Apirone has the most interesting accident. Create a wallet with one POST and the response body contains a transfer-key, the credential that authorises transfers out of that wallet. Nothing documents revoking or rotating it — but because it is per wallet rather than per account, a leak exposes one wallet instead of a treasury. Containment as a side effect of the object model still beats no containment.

One more silence, in the other direction. Where a provider publishes the IPs its callbacks come from, you can check an inbound webhook by origin as well as by signature. BlockBee publishes two (51.77.105.132 and 135.125.112.47) and asks you to allow them so security systems do not drop its retries. OxaPay's SDK notes say to "Whitelist OxaPay IPs on your firewall (ask support)" — a control you can only use after opening a ticket.

The rotation test: what replacing a leaked key costs

Here is the test we would apply to any gateway before integrating. Assume the credential is already public: how long until it is worthless, and what does getting there cost you? Crypto gateway API key security is mostly this one question, and the answers are worse than the marketing suggests.

What replacing a money-moving credential costs, from each provider's own documentation, 16 October 2026.
Gateway	Documented path	What it costs	Worst case
BTCPay Server	Delete, re-create with the same permissions	One secret redeploy	None documented
BlockBee	Revoke on the API Keys page, generate another	V2 needs the Recovery Key	Lose both: funds "permanently inaccessible"
Cryptomus	Generate a new Payout key (2FA required)	"Withdrawals ... blocked for 24 hour"	A full day with no payouts, mid-incident
OpenNode	"You must make a new withdrawal API key"	Redeploy, re-enter the allowlist	A key with no allowlist cannot be fixed in place
OxaPay	Generate another key of that type	Re-entering Allowed IPs	Rotation appears only in SDK notes
NOWPayments	Not documented for keys	—	A removed address stays payable while pending
CoinGate	Not documented	Unknown until you need it	Reference last updated June 2025
Apirone	Not documented	Unknown	Contained to one wallet by design
Plisio	Not documented	Unknown	One key, every endpoint

Neon-green-on-black table headed The rotation test, showing what replacing a money-moving credential costs at each of nine gateways. BTCPay Server: delete and re-create with the same permissions, one secret redeploy, no worst case documented. BlockBee: revoke and generate another, V2 needs the Recovery Key, and losing both leaves funds permanently inaccessible. Cryptomus: generate a new payout key with two-factor, which blocks withdrawals for 24 hours, a full day with no payouts mid-incident. OpenNode: you must make a new withdrawal API key, redeploy and re-enter the allowlist. OxaPay: generate another key of that type and re-enter allowed IPs, with rotation appearing only in SDK notes. NOWPayments, CoinGate, Apirone and Plisio document no path at all — Five of nine do not mention rotation at all, which in practice means a support ticket written under time pressure.

Four of nine document a path, and one of those four prices it at a day of downtime. Five do not mention it at all, which in practice means a support ticket written under time pressure, in whatever timezone the provider answers.

So build the assumption in: treat the credential as unrotatable unless the documentation says otherwise, and put every control you do have in front of it — a dedicated payout key, an allowlist, a destination whitelist, and the key itself nowhere near a repository or a client bundle.

Six questions to ask before you integrate

Ask these of any gateway, including the nine here. Key models change more often than fee tables.

Can one credential both invoice and withdraw? If so, your storefront holds a withdrawal key whether you call it that or not.
Is there a separate payout credential, and does getting it need 2FA? Cryptomus requires it; most do not ask.
Can the key be restricted by IP, and changed later? OpenNode and OxaPay: yes to the first, no to the second.
How do I replace a compromised key, and what breaks while I do? Five of nine do not answer. Get it in writing before you need it.
Can destinations be whitelisted, and how fast can one be removed? NOWPayments is the fullest implementation, pending-removal window included.
Where does the key travel? Header or query parameter decides whether it lands in your logs.

The one-line summary. If you need a credential that genuinely cannot move money, self-host and use a permission string. If you need a hosted gateway, pick one that separates the payout leg, turn on every fence it offers on the day you integrate rather than the day you are breached, and write down what rotation will cost — because five of the nine will not.

Credential design is one layer. The others are where the money sits and who can stop it: how gateways screen inbound payments and how long a compliance hold can last both override every control on this page.

Related Articles

The credential model is set on the day you integrate. Check it before the leak, not after.

We track fees, custody, KYC and settlement for every processor in the directory. BTCPay Server is the only one in this set with real permission scopes; NOWPayments has the fullest destination and origin whitelisting.

Compare Crypto Payment Gateways →

Affiliate disclosure: Payyd earns a commission if you sign up to some providers linked on this page. It changes none of the key types, permission strings or limits reported here, all of which come from the providers' own reference pages and are linked below.

FAQ

Can you restrict a crypto payment gateway API key to one permission?

On one of the nine we read. BTCPay Server publishes 48 permission strings and lets you issue a key carrying only the ones you pick, narrowed to a single store with a colon and the store ID. The hosted eight separate by key type at best — OxaPay has three, Cryptomus and OpenNode separate the payout leg, BlockBee separates by key generation — and CoinGate, Plisio and Apirone document no scoping at all.

Do crypto payment gateways support IP whitelisting?

Some do, for payouts only. OpenNode attaches one to a withdrawal API key, OxaPay offers Allowed IPs on its Payout key, and NOWPayments has an account-level IP whitelist. At OpenNode and OxaPay the list is set when the key is generated, so plan a static egress IP first. The other six document no per-key allowlist.

What happens if my crypto gateway API key is leaked?

It depends which key it is. A payment or invoicing key lets an attacker create invoices, which is a nuisance rather than a theft. A payout or account-wide key is a withdrawal credential. Revoke it where the provider documents a path — BlockBee and BTCPay Server both do — and open a support ticket where it does not, which is five of the nine. Then check your destination whitelist: an attacker who cannot change it cannot send funds anywhere new.

Does a separate payout API key actually help?

Yes, and it is the highest-value control available on a hosted gateway. The credential sitting in your web application cannot move funds, so the common leak — a key in a repository, a log, a CI variable or a client bundle — stops being a theft. Cryptomus, OpenNode, OxaPay and BlockBee all offer a way to keep the money-moving credential out of the storefront.

Do crypto payment gateways require two-factor authentication?

Rarely as a condition of anything. Cryptomus is the exception: its instructions say to "Bind two-factor authentication if you haven't already done it" before you can generate a Payout key. NOWPayments requires a 2FA code to add a payout address to the whitelist, and another to remove one. Elsewhere 2FA is a login setting, with nothing tying it to issuing credentials or moving funds.

Should I whitelist my payout address or my server's IP?

Both, if the provider offers both, because they stop different attacks. An IP allowlist stops a stolen key being used from elsewhere. A destination whitelist stops funds reaching an address you did not approve, even from your own server — the stronger of the two against a compromised host, which is why NOWPayments routing it through custody with a 2FA confirmation is a design and not a formality.

How often should I rotate a crypto gateway API key?

BlockBee is the only provider here that offers guidance, and its answer is "Rotate keys periodically" with no interval. The more useful question is whether you can rotate at all: the cost ranges from a redeploy to a 24-hour payout freeze to an undocumented support ticket. Rotate on events you can see — a contractor leaving, a key in a log, a host migration — rather than on a calendar.

Sources

Primary documentation, read 16 October 2026:

BTCPay Server — Greenfield API reference (48 permission strings, store-scoped syntax)
Cryptomus — Getting API keys (2FA prerequisite, 24-hour withdrawal block)
BlockBee — Authentication, API Key V1 vs V2 (Recovery Key, revoke and regenerate)
OpenNode — Withdrawal API keys and IP whitelisting (creation-time allowlist)
OxaPay — Payout API (Allowed IPs for transfers)
OxaPay — Merchant API ("grants access to your OxaPay account")
NOWPayments — API integrations and payout controls (30 Sep 2026: pending removal, IP whitelist)
NOWPayments — Dashboard and whitelisting (30 Jun 2026: 15-minute 2FA code, REQUESTED status)
CoinGate — API authentication (token header only; dated June 2025)
Plisio — API documentation ("This secret key will be used with all API calls")
Apirone — Wallet API (per-wallet transfer-key in the response)