Rotate the key immediately on the Paystack dashboard. Do not investigate first. Rotate first, then check your transaction and transfer history for unauthorized activity. Update all deployments with the new key. Review audit logs. Contact Paystack support if you find unauthorized transactions. Then install prevention measures like pre-commit hooks and secret scanning.
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.
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:
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.
Get weekly developer tips
Join 25,000+ developers. Practical guides, job tips, and new content — straight to your inbox.
No spam. Unsubscribe anytime.
Now that the key is rotated and your services are running with the new key, investigate what happened during 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.
In the Paystack dashboard, go to Transactions and filter by the exposure window. Look for:
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.
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.
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:
When you contact them, provide:
Paystack may be able to:
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:
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.
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.
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.
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.
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:
sk_ pattern.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:
Store the report securely. It may contain sensitive details about your security posture and should not be publicly accessible.
KES 2,999
The definitive guide to building payment systems with Paystack — from your first transaction to production-grade payment infrastructure across Africa. 9 modules, 47 lessons. Free preview available.
Start Paystack Course