What to Do If Your Paystack Secret Key Leaked

Do not investigate how the leak happened. Do not try to figure out who has the key. Do not check if anyone has used it yet. Rotate first. Investigate second.

Every minute the old key is active after a leak is a minute an attacker can use it to move money out of your account. The investigation can wait. The rotation cannot.

1. Log in to the Paystack dashboard at dashboard.paystack.com
2. Go to Settings, then API Keys & Webhooks
3. Generate new keys
4. Copy the new secret key immediately. Paystack will not show it again after you navigate away.

The old key is invalid the moment you generate new ones. Any request using the old key will return 401 Unauthorized. This means your live application will also break until you update it with the new key. That is acceptable. A few minutes of payment downtime is vastly better than an attacker draining your account.

With the new key in hand, update every place the old key was used:

• Production server environment variables. Update on Vercel, Railway, Render, or wherever your app runs.
• Staging and development environments. If you leaked a test key, update those too.
• Background workers and cron jobs. Any service that calls the Paystack API needs the new key.
• Webhook handlers. Your webhook signature verification uses the secret key. Update it or webhooks will fail verification.
• Third-party services. If you stored the Paystack key in a third-party service (a no-code tool, a Zapier integration, a monitoring service), update those too.

Trigger redeployments for all affected services. Verify each one processes a test transaction successfully before moving on.

For detailed platform-specific update instructions, see Paystack keys in Vercel, Railway and Render.

Now that the key is rotated and your services are running with the new key, investigate what happened during the exposure window.

Determine the Exposure Window

Figure out when the key was first exposed and when you rotated it. The exposure window is the time between these two events. If the key was committed to a public GitHub repo three weeks ago and you just discovered it, the exposure window is three weeks.

Review Transaction History

In the Paystack dashboard, go to Transactions and filter by the exposure window. Look for:

• Transactions you do not recognize
• Transactions with unusual amounts
• Transactions from customers you do not recognize
• Transactions at unusual times (middle of the night in your timezone)

Review Transfer History

Transfers are the most dangerous thing an attacker can do with your key. Go to Transfers in the dashboard and look for any transfers you did not initiate. An attacker can create a transfer to send money from your Paystack balance to any bank account.

Review API Logs

If you have application-level logging, search your logs for Paystack API calls during the exposure window. Look for calls you did not make, especially to the /transfer endpoint.

Check Customer Data Access

An attacker with your secret key can read all customer data: emails, names, card details (last four digits and expiry), and transaction history. If you believe customer data was accessed, you may have a data breach notification obligation under the Kenya Data Protection Act or Nigeria Data Protection Act.

If you find unauthorized transactions or transfers, contact Paystack support immediately:

• Email: support@paystack.com
• Dashboard: Use the in-app chat/support feature

When you contact them, provide:

1. Your business name and Paystack account email
2. The exposure window (when the key was leaked and when it was rotated)
3. A list of suspicious transactions or transfers (include references)
4. How the key was leaked (git commit, log file, etc.)

Paystack may be able to:

• Freeze suspicious transfers before they settle
• Provide API access logs showing which endpoints were called with your key
• Help identify the source of unauthorized activity
• Guide you through any regulatory notification requirements

Even if you do not find unauthorized activity, it is good practice to notify Paystack that a key rotation happened due to a security incident. They may have additional visibility into your account activity that you do not have from the dashboard.

With the immediate crisis handled, find and fix the root cause. Common sources of Paystack key leaks:

Git Commits

The most common source. The key was hardcoded in a source file or a .env file that was committed. Scan your repository:

git log -p --all -S 'sk_live_' -- .
git log -p --all -S 'sk_test_' -- .

If found, clean the git history with git filter-repo and install pre-commit hooks. See detection and remediation for committed keys.

Log Files

Application logs, error tracking services (Sentry, Bugsnag), or request logging middleware may have captured the key in Authorization headers or request bodies. Search your logging service for sk_live_ and sk_test_ patterns.

Chat Messages and Documentation

Keys shared through Slack, WhatsApp, email, or internal documentation. These are harder to find but important to clean up. Delete the messages or documents containing the key.

Client-Side Exposure

The secret key was accidentally used in frontend code (using NEXT_PUBLIC_ prefix for the secret key, or passing it in a client-side API response). Check your frontend bundle and API responses.

Team Member Departure

A former team member retained access to the key after leaving. This is not a "leak" in the traditional sense, but it is a security risk. Rotation is the correct response.

After resolving the incident, put measures in place to prevent it from happening again:

1. Pre-commit hooks. Install git-secrets or gitleaks as a pre-commit hook to block commits containing key patterns.
2. CI pipeline scanning. Add gitleaks to your CI pipeline to catch keys that bypass pre-commit hooks.
3. GitHub secret scanning. Enable secret scanning and push protection on your GitHub repository.
4. Environment variable validation. Add startup checks that verify keys are loaded from environment variables, not hardcoded.
5. Logging sanitization. Configure your logging to redact Authorization headers and any values matching the sk_ pattern.
6. Access audit. Review who has access to your Paystack dashboard and hosting platform. Remove unnecessary access.

For detailed setup instructions for each measure, see detection and remediation for committed keys.

Write an internal incident report. This is important for team learning, for compliance requirements, and for demonstrating due diligence if a regulatory question arises later.

A good incident report covers:

• Timeline. When the key was exposed, when the exposure was discovered, when the key was rotated, and when the incident was fully resolved.
• Impact. Were any unauthorized transactions or transfers made? Was customer data accessed?
• Root cause. How was the key exposed?
• Response actions. What did you do to contain and resolve the incident?
• Prevention measures. What changes are being made to prevent recurrence?

Store the report securely. It may contain sensitive details about your security posture and should not be publicly accessible.