Reevit
Unified payments, billing, and orchestration for Africa
5 followers
Unified payments, billing, and orchestration for Africa
5 followers
Reevit is a payment operations stack for teams managing multi-PSP commerce infrastructure. It integrates the PSPs you already use, including Paystack, Stripe, Flutterwave, Monnify, Hubtel, and M-Pesa. It standardizes authentication, metadata, and transaction states across both sandbox and live modes. With BYOK, workflow automation, unified webhooks, visibility, and built-in billing logic, Reevit eliminates fragile glue code and transforms payments into a managed, scalable system.
- Who am I?
I am Felix Yeboah - Jefferson
- Why I build it?
I was working on an e-commerce app for a client who sells natural spices. Everything was going great until my phone started ringing, she couldn't use the app because the payment service kept failing. While I tried to figure out what was going wrong, she had to go back to selling offline.
The problem? The webhook from the payment service just wasn't reliable. Sometimes I'd get the callback, but most of the time... nothing. I suggested switching to a different payment provider, but she was hesitant. When she finally agreed, I had to rewrite basically the entire codebase to make it work with the new service.
That's when it hit me that I can't be the only developer dealing with this. And having worked at Primer.io, I had seen firsthand how these problems could be solved differently.
So I started planning. My initial goal was simple: connect two or more payment providers and get consistent responses no matter which one I'm using. Without this, every time you switch providers, you're stuck rewriting huge chunks of code just to handle different request formats and responses. With my solution, you send the same request format to any provider and get back a standardized response.
It worked exactly how I hoped. Now I can set one provider as the default and others as backups and the system automatically routes payments to a healthy provider when the primary one isn't available. This solved the client's problems completely. She's now using multiple providers without any headaches.
I know what you're probably thinking; what about security? The API keys and secrets are completely safe. I'm using envelope encryption with AES-256-GCM, and credentials are only decrypted in memory when actually needed for a transaction.
I also wanted to add fraud prevention workflows. Yes, most payment providers have their own fraud checks, but I wanted something where merchants can set rules based on country, purchase amount, block specific card bins, all before we even touch the payment provider's API.
I'm still refining things, but I'm confident that with more testing over the next few months, this can become a real product that developers and merchants actually want to use. The philosophy is simple: Bring Your Own Keys (BYOK).
Right now, I'm building out workflows for email templates, SMS notifications, and team alerts through Slack or Teams. For example, when a payment succeeds, the customer gets an email and SMS (if configured), while the merchant gets notified on Slack about the transaction. All of this will be configurable through the dashboard, again using your own API keys.
I genuinely believe this will solve real problems that developers and merchants face every day, and seriously speed up how fast we can ship payment features.