Crypto Payment Security: A Merchant's Checklist

API key hygiene

Your Solpaygate API key is the credential that lets a server tell us "issue this payment against my company." Anyone who has it can create payments, read your history, and update parts of your configuration. Treat it like a database password.

The basics still apply, and they're worth restating because most breaches trace back to one of these three mistakes:

• Never embed the key in a frontend bundle. If you can grep it out of your Vite build, so can everyone else. All Solpaygate API calls belong on your server.
• Use environment variables or a secret manager, not a checked-in config file. GitHub secret scanners will catch obvious leaks, but plenty of quieter ones slip through.
• Rotate keys on a schedule — every 90 days is a sensible default — and immediately when someone leaves the team.

Solpaygate lets you have multiple keys per company, so rotate by issuing a new key, deploying it, and then revoking the old one — no downtime window required.

Webhook signature verification

The webhook endpoint on your side is exposed to the public internet. Anyone who guesses the URL can send it fake payloads. The only thing between them and your credit-the-account code is signature verification.

Every Solpaygate webhook is signed with an HMAC-SHA256 of the raw request body, using your webhook secret. Verify the signature before parsing anything else:

const expected = crypto
  .createHmac('sha256', WEBHOOK_SECRET)
  .update(rawBody)
  .digest('hex');
if (!crypto.timingSafeEqual(
  Buffer.from(expected),
  Buffer.from(req.headers['x-solpaygate-signature'])
)) return res.sendStatus(401);

Two things to double-check. First, compute the HMAC over the raw request body — not the parsed JSON, because whitespace and key order can differ. Second, use a constant-time comparison; a naive triple-equals leaks timing information an attacker can use to forge signatures over many attempts.

Master wallet protection (2FA)

Your master wallet is where all payments ultimately land, and it's the single largest concentration of value in your Solpaygate account. Changing its address is the highest-impact action a merchant can take, so we require TOTP-based 2FA on that operation.

A few operational rules that pay off:

• The TOTP secret should live on a hardware key or a device that is not your primary work laptop.
• Print recovery codes and put them somewhere physical. If you ever lose your phone, you'll be glad you did.
• Sweep the master wallet balance to cold storage on a regular schedule. Hot balances should cover a day or two of expected volume, not a year of settlement.
• Set up alerts on unusually large outgoing transfers so you notice within minutes if the wallet is ever misused.

Solpaygate is a non-custodial gateway — we never hold your funds — but that also means the responsibility for what happens to the master wallet address sits squarely with you.

Auditing payment flows

You want to be able to answer, at any moment, three questions: what payments were created in the last 24 hours, which ones confirmed, and which of those credited a customer account. Persistent logs of your side of that trail — request/response IDs, webhook receipts, credit journal entries — take a week to build and save weeks of investigation later when something looks off.

Store a Solpaygate paymentId on every credit event in your ledger. If a customer complains "I sent you money and didn't get credit," a query on that ID against the Solpaygate dashboard gives you the truth in under a minute. Reconcile the totals daily; a small nightly job that compares Solpaygate-side confirmed payments to your own credit journal will catch bugs long before customers do.

Incident response

If you suspect a leaked API key or a compromised admin account, do these things in this order, without stopping to investigate first:

1. Revoke the affected API key from the Solpaygate dashboard.
2. Rotate the webhook secret so any signature the attacker can generate immediately stops working.
3. Change the master wallet address (2FA required) to one whose seed hasn't been on the same machine as the compromised credential.
4. Pull the last 30 days of payment logs for forensic review.
5. Then investigate the root cause.

Losing a few payments to a temporary outage is manageable. Losing a wallet is not — every minute you delay revocation is another minute an attacker can create payments or update configuration. Detailed webhook and rotation patterns are covered in our webhooks guide; keep it bookmarked next to your incident runbook.