What if I built the integration on my own Paystack account?

This is a problem. You need to migrate: have the client create their own Paystack account, re-create any subaccounts, plans, or customers in the new account, update production environment variables to the new keys, and test end-to-end. For future projects: always build on the client's Paystack account from day one. Your account should only contain your own test/sandbox integrations.

Should I keep a copy of the client's API keys for support purposes?

No. After handover, the client should rotate their keys and you should have no access. For ongoing support, the client can temporarily share a new key or grant limited dashboard access on a per-issue basis. Storing client API keys creates a liability and is a security risk — if your devices are compromised, the client's payment account is at risk.

What if the client loses their Paystack dashboard credentials?

That is between the client and Paystack — they can use Paystack's account recovery process. This is exactly why the integration should be on the client's own account (which they control and can recover) rather than yours. Document this in your handover: "To recover your Paystack account access, visit paystack.com → Forgot Password."

Handing Over a Paystack Integration to a Client Safely (2026 Checklist)

Handing Over a Payment Integration to a Client Safely

Handover checklist: 1) Client creates their own Paystack account and registers the business (you should never build on your own Paystack account for a client). 2) Generate live API keys in the client's Paystack account. 3) Update production environment variables with the client's keys. 4) Transfer webhook URL to the client's server/domain. 5) Revoke any access you had to the client's server or API keys. 6) Deliver documentation: env var list, webhook handler location, how to rotate keys, how to view settlements. 7) 14-day post-handover support window.

Safe Handover Checklist

Item	Who Does It	Done?
Client has their own Paystack business account (verified)	Client	☐
Live API keys generated in client's Paystack account	Client (you assist)	☐
Production env vars updated: PAYSTACK_SECRET_KEY, PAYSTACK_PUBLIC_KEY, PAYSTACK_WEBHOOK_SECRET	Developer	☐
Webhook URL points to client's domain (not a test/staging URL)	Developer	☐
Webhook URL registered in Paystack dashboard	Developer / Client	☐
Test transaction on live mode verified end-to-end	Both	☐
Documentation delivered: env var list, code location, API key rotation steps	Developer	☐
Client's IT team can access and restart the production server	Client	☐
Developer's server/hosting access revoked	Client (developer requests)	☐
Final invoice issued and payment received	Developer	☐

What Documentation to Deliver

Your handover documentation should include:

Environment variable reference — every env var the system depends on, with description, where to get the value, and example format.
Where the payment code lives — file paths for webhook handler, checkout initialization, verification.
How to rotate API keys — step-by-step: Paystack dashboard → API keys → regenerate → update env var → restart server.
How to add/remove webhook URLs — Paystack dashboard path.
How to view settlements — Paystack dashboard → Settlements.
Who to call if payments stop working — Paystack support email/phone, and your maintenance retainer offer.

Learn More

See maintaining payment integrations as recurring revenue for post-handover retainer structures.

Sign up for the McTaba newsletter

Key Takeaways

✓Never build a client's Paystack integration on your own Paystack account — always use the client's account.
✓API keys must be in the client's environment variables, not in your possession, after handover.
✓The client should be able to rotate their own API keys without calling you.
✓Document every environment variable the integration depends on.
✓Revoke your own server/hosting access as part of handover — leave a clear audit trail.

Frequently Asked Questions

What if I built the integration on my own Paystack account?: This is a problem. You need to migrate: have the client create their own Paystack account, re-create any subaccounts, plans, or customers in the new account, update production environment variables to the new keys, and test end-to-end. For future projects: always build on the client's Paystack account from day one. Your account should only contain your own test/sandbox integrations.
Should I keep a copy of the client's API keys for support purposes?: No. After handover, the client should rotate their keys and you should have no access. For ongoing support, the client can temporarily share a new key or grant limited dashboard access on a per-issue basis. Storing client API keys creates a liability and is a security risk — if your devices are compromised, the client's payment account is at risk.
What if the client loses their Paystack dashboard credentials?: That is between the client and Paystack — they can use Paystack's account recovery process. This is exactly why the integration should be on the client's own account (which they control and can recover) rather than yours. Document this in your handover: "To recover your Paystack account access, visit paystack.com → Forgot Password."

Ready to build real-world apps?

Join the McTaba Labs full-stack marathon (4 months full-time · 6 months part-time). Learn M-Pesa, USSD, and WhatsApp engineering while shipping 8 production apps.

Apply to the McTaba Marathon