When someone signs up for Reclaim, the first thing we ask for is their Paystack secret key — full access to a live payment account, not a scoped, read-only token.
That's not a small ask. There's no setting on Paystack or Flutterwave today that lets a business say “give this third-party tool read-only access to failed transactions and nothing else.” It's all or nothing.
Most tools that ask for this kind of access don't talk about it much. The security section, if it exists at all, is usually a paragraph of reassuring but vague language — “bank-level encryption,” “your data is safe with us” — without much behind it. I wanted to write down what actually sits behind that promise for Reclaim, partly because I think founders deciding whether to trust a small, unfamiliar tool with their payment keys deserve more than a vague paragraph, and partly because writing it down forced me to actually verify it was true.
Encryption at rest, and what that actually means
Every secret key Reclaim stores is encrypted using AES-256-GCM before it ever touches the database — a standard, well-tested encryption approach, not something custom or unproven.
The detail that matters more than the algorithm name: the encryption key itself lives separately from the encrypted data. It's not sitting in the same database as the keys it protects, and it's not hardcoded anywhere in the codebase — I checked the full commit history specifically for this, not just the current state of the code. If someone got read access to the database alone, they'd get an unreadable string, not a usable Paystack key.
Where a plaintext key can and can't go
This is the part that's easy to get wrong quietly, without realizing it. A secret key can leak in places that have nothing to do with the main storage system — error logs, analytics events, API responses, debugging tools.
I went through every place in the codebase where a merchant's connected Paystack secret key gets decrypted and used — there are exactly three, all tied to specific, necessary operations: generating recovery SMS links for a merchant's own failed transactions, re-verifying a payment before marking a recovery as complete, and powering the “analyze failed payments” view on a merchant's own dashboard. None of them is an admin tool or a debugging shortcut. I also checked every logging call, every analytics event, and every API response that touches payment data, specifically looking for any path where a plaintext key could end up somewhere it shouldn't. None did.
I also added something that wasn't there originally: every time one of those three paths decrypts a key, it's logged — not the key itself, just who accessed it, when, and through which part of the system. Nothing today would let a key slip out unnoticed there, but if that ever changed as the codebase grows, this is what would catch it.
There's one thing that doesn't cover, and I don't want to round it up to zero. Reclaim also stores a second kind of secret — a card-authorization code, used to auto-charge a merchant for their own Reclaim subscription, not to touch their customers' payments. It's encrypted the same way, with the same key. But it's decrypted from exactly one other place: an admin-only invoicing route I run myself to charge subscription fees. That path exists, it works correctly, and it doesn't leak the code anywhere — but it isn't wired into the access log I just described. It should be. I'm adding it, not because I found anything wrong there, but because “every decrypted key is logged” wasn't quite true until that path is covered too, and I'd rather say that plainly than let the sentence do more work than it's earned.
Revocation that actually revokes
A “revoke access” button is only as good as what happens when you click it. If it just flips a flag while the key sits in the database unchanged, that's not real revocation — it's the appearance of one.
Reclaim's revoke function does a hard delete. The key is gone, immediately, and every part of the system that would use it fails safely rather than falling back to a cached copy. This was worth testing directly, not just trusting that the code did what it looked like it should do.
What I haven't done yet, and why I'm saying so
I don't think it's honest to write a post like this and only list what's done. A few things are still on the list:
The access log I described above doesn't yet cover the admin-side billing-authorization path mentioned earlier. That's the next thing I'm wiring up, not the last.
The encryption key currently lives in an environment variable, not a dedicated secrets manager. That's a correct and common approach at this stage, but it's not the most robust one available, and there's no key rotation process yet — if the encryption key ever needed to change, that would currently require a manual process that doesn't exist today.
There's no formal incident response plan written down yet — the kind of document that says, plainly, what happens in the first hour if something goes wrong. That's next on my list, not because something's wrong, but because the right time to write that plan is before you need it, not during.
Why write this at all
Nobody asked me to publish a breakdown of my own encryption implementation. I'm doing it because I think the businesses evaluating Reclaim — and probably any similar tool — deserve more than a trust badge and a paragraph of reassuring language. If a tool is asking for full access to your payment account, “we take security seriously” shouldn't be something you have to take on faith.
If you're evaluating any tool that asks for this kind of access — Reclaim or otherwise — it's fair to ask exactly these questions: what's encrypted, where the encryption key lives, who can see a plaintext credential, and what actually happens when you revoke access. If a company can't answer clearly, that's worth knowing before you hand over the key, not after.
Reclaim helps Paystack-powered subscription businesses recover revenue lost to failed payments through automated SMS follow-up. Learn more →