Key Security for Merchants Accepting Crypto

What are you actually protecting?

It depends on the custody model, and the two cases look nothing alike.

Custodial. You hold API credentials. Funds sit with the provider until settlement. A compromised credential lets an attacker act as you within whatever that credential can do, which is why what it can do matters more than how long it is.

Non custodial. You hold keys, or an extended public key derived from them. Payments arrive in a wallet you control and nobody else can move them, including you if the keys are lost.

The credential that matters

The outbound one. An inbound API key can create invoices and read payments, so a leak is embarrassing rather than expensive. An outbound key can move your balance, and a leak is the balance.

Providers with a serious payout product separate the two, let you revoke them independently, and put a value threshold above which a human confirms. Providers without that treat one credential as sufficient for both directions, which means your inbound integration carries outbound risk for no reason.

Ask which model you are getting. If it is one credential, keep it somewhere much more restricted than an ordinary API key, and press for the separation.

What controls are worth having?

An approval threshold on outbound payments, set low enough to be meaningful. Withdrawal address allowlisting where the provider supports it, so a compromised credential can only send somewhere you already trust.

Separate credentials per environment, and a check that nothing in production falls back to test configuration. Rotation on staff departure, which sounds procedural and is the failure mode that actually happens at small companies.

Alerting on outbound activity, delivered somewhere a human reads rather than to a log nobody opens.

Non custodial specifics

If you hold real keys, the failure mode changes from theft to loss, and loss is more common. A wallet whose recovery phrase exists in one place, known to one person, is a business continuity risk rather than a security posture.

Treat it the way you would treat any other single point of failure: more than one person able to recover it, stored somewhere that survives the loss of an office and the departure of an employee. The glossary entry covers what the model buys you in exchange for taking this on.

A minimum control set

Separate credentials for inbound and outbound operations, revocable independently. A value threshold above which an outbound payment needs a second approval. Withdrawal address allowlisting where the provider supports it. Alerting on outbound activity, delivered somewhere a human reads.

None of this is exotic and not every provider offers all of it. Which parts are available is a fair question to ask during evaluation rather than after.

Rotation, and why it gets skipped

Because nothing breaks when you do not. Credentials outlive the people who created them, and a business three years into an integration frequently has keys whose provenance nobody remembers.

Tie rotation to something that already happens: staff departures, an annual review, a provider contract renewal. A schedule nobody owns is a schedule nobody follows.

For non-custodial setups specifically

The recovery phrase is a business continuity artefact, not a secret one person keeps. More than one person able to recover it, stored somewhere that survives the loss of an office and the departure of an employee.

The common failure is not theft. It is a phrase in one place, known to one person, who leaves. Treat it the way you would treat any other single point of failure in the business.

What to verify at setup

That test and production credentials are genuinely separate. That revoking one does not silently break the other. That your alerting actually fires, tested deliberately rather than assumed.

The payouts page covers the outbound controls in more depth, since that is where the exposure concentrates.

Where to go next

Mass payouts covers the outbound flow where this exposure concentrates. The custody guide covers which model you are securing, and the non-custodial entry covers what taking the keys yourself trades away.

What to do after an incident

Revoke first, investigate second. An outbound credential you suspect is compromised should be dead before anybody starts reading logs, because the cost of a false alarm is one reissued key and the cost of hesitation is the balance.

Then check whether the provider offers activity history at credential granularity, so you can see what was done with which key. Not all do, and it is worth knowing before you need it rather than during.

Access review as a habit

Once a year, list every credential that exists, what it can do, and who has it. Most businesses discover at least one key nobody can account for, and the exercise takes an hour.

The same review should cover dashboard access, which is frequently broader than API access and gets less attention. A former employee with a provider login can often do more than a leaked read-only key.

The thing worth automating

Alerting on outbound activity, delivered somewhere a human actually reads rather than to a log file. Detection speed is the whole difference between a single unauthorised payout and a drained balance, and it is the cheapest control on this list to implement.

A note on shared credentials

A single API key pasted into a shared document, a chat channel, or three developers’ local environments is the most common real-world exposure in small teams, and it is invisible until something goes wrong.

Use per-environment credentials at minimum, and per-person dashboard access rather than a shared login. Neither costs anything, both make an incident investigable, and the absence of both is what turns a small problem into an unanswerable one.

Security work in this category is unglamorous and mostly consists of separating things that arrived joined together: inbound from outbound credentials, environments from each other, and individual access from shared logins. None of it is difficult, and the absence of all three is what most incidents have in common.