Crypto Payment Security Best Practices for Merchants

Crypto payment security for merchants comes down to a handful of disciplines: keep settlement funds in cold storage or multisig rather than a hot wallet, manage private keys with least privilege and rotation, verify every webhook signature before acting on it, scope and protect your API keys, and test the entire flow on testnet before touching live funds. Non-custodial settlement removes the risk of a provider holding your money — but it makes your own key hygiene the control that matters most, because there is no custodian to recover from your mistakes.

We build Settlematic, a non-custodial gateway, so several practices below concern the responsibilities that non-custodial settlement hands to you. They apply regardless of provider.

Wallet hygiene: separate hot from cold

The single highest-leverage practice is to stop treating one wallet as both your till and your vault. Split funds by purpose and exposure:

• Cold storage for reserves. Hold long-term settlement balances in an offline, hardware-backed wallet with no persistent internet exposure. This is your vault; it should move rarely.
• A small hot wallet for operations. Keep only what you need for near-term refunds and outflows in an online wallet. Treat its full balance as the maximum you can afford to lose to a compromise.
• Fresh receiving addresses per invoice. Address reuse leaks transaction graph information and weakens privacy; a good gateway issues a unique address per invoice by default.
• Sweep on a schedule, not automatically to a hot key. Move accumulated settlements to cold storage deliberately, with review, rather than auto-forwarding to a single always-online key.

Multisig and cold storage for settlement

For any business holding meaningful crypto reserves, multisig is the difference between a single-key compromise being a nuisance and being a catastrophe. A multisig wallet requires M-of-N approvals to move funds, so stealing one key — or one employee going rogue — is not enough.

Distribute multisig signers across people and devices so no single compromise or single person can move funds. Document a recovery procedure for a lost signer before you need it, and rehearse it.

Webhook signature verification: never trust an unsigned event

This is the most common integration mistake, and the most dangerous. Your gateway notifies your backend that an invoice was paid via a webhook. If your code trusts that request without verifying it, anyone who discovers or guesses your webhook endpoint can POST a fake "payment received" event and trigger fulfilment or account credit for free.

• Verify the cryptographic signature on every webhook using the shared secret or public key your provider supplies, and reject anything that fails.
• Treat the webhook as a hint, not proof — confirm the payment independently against on-chain state or the provider's API before releasing goods, especially for high-value orders. See on-chain payment confirmation.
• Enforce idempotency: the same payment event may arrive more than once, so key your processing on the payment/invoice ID to avoid double-crediting.
• Guard against replay: check timestamps and reject stale or duplicate signed payloads.

The full reconciliation pattern — matching signed webhooks to confirmed on-chain payments — is covered in crypto payment webhooks and reconciliation.

Key and secret management

Private keys and API keys are the crown jewels; handle them like it. Follow established guidance such as NIST SP 800-57 on key lifecycle and the OWASP testing guide on secret handling.

• Least privilege: issue API keys with the narrowest scope that works, and separate read-only keys from keys that can move funds or change settings.
• Never client-side: API keys and signing secrets belong on your server, never in browser code, mobile bundles, or public repos.
• Rotate regularly and on suspicion: rotate keys on a schedule and immediately if a device or employee is compromised or departs.
• Use a secrets manager: store secrets in a dedicated vault or KMS, not in .env files committed to source control.
• Protect seed phrases offline: back up wallet seeds on paper or metal in physically secure locations; never photograph or store them in cloud notes.

Testnet first: on-chain payments are final

Because on-chain payments cannot be reversed, mistakes are permanent. Validate everything against a testnet or sandbox before going live:

• Confirm the settlement address is correct and under your control, across every chain you enable.
• Test underpayment, overpayment, and late-payment handling, not just the happy path.
• Verify your webhook signature check actually rejects a tampered payload.
• Confirm the number of confirmations you require matches your risk tolerance per chain.

Settlematic offers a free sandbox for exactly this. See test crypto payments in a sandbox and the developer docs at /developers.

Where non-custodial changes the threat model

Non-custodial settlement removes the provider as a place your funds can be frozen, hacked, or lost in bankruptcy — a large category of risk gone. But it hands you full responsibility for the keys. There is no support line that can reverse a transfer or recover a lost seed. The honest trade is that you exchange counterparty risk for operational risk, and operational risk is the kind you can actually control with the practices above.

Settlematic is non-custodial by construction — deposit addresses bound at issuance, keys never held by us, signed webhooks, and a free testnet sandbox — with SOC 2 in progress. The architecture is documented on our security page, and integration guidance lives at /developers.

Start by running the full flow safely: open the free sandbox, wire up signature-verified webhooks, and confirm settlement to your own cold-storage or multisig wallet before you accept a live payment.

General security guidance, not financial or security-audit advice; references to NIST and OWASP are public standards, verified 7 September 2026.