01 Failover
A declined charge isn’t a lost sale.
When a provider declines or stops answering, the same charge moves to the next one in the merchant’s chain, inside the same tap. Nobody has to ask the customer to try again.
Payments2025Live
Payments that don’t miss. One provider goes down, the customer never knows.
Formerly Primeflow
- Role
- Founder & engineer
- Services
- Product design, frontend, backend, infrastructure
- Providers
- Paystack, Hubtel, Flutterwave · and five more
- Year
- 2025 · serving early merchants
(01) The brief in one line
Payments that keep working when the provider behind them doesn’t.
A The problem
Felix was building the store for Miss Cookie Spices when payments started failing. The provider’s webhook had gone unreliable: sometimes it fired, sometimes total silence.
Switching providers meant rewriting almost the whole integration.
B The question
If one client hit this, how many developers were quietly accepting broken payment flows?
Enterprise teams have orchestration layers like Primer. Builders starting from scratch had nothing that simple.
C The approach
A universal remote for payments.
- 01Integrate once. One snippet, any provider behind it.
- 02One shape. Same request and response, so switching never touches business logic.
- 03No downtime. Whichever provider is answering takes the charge.
(02) The product
Everything after the customer taps Pay.
Four screens
from reevit.io
02 Recurring
Retries that change lanes.
Subscriptions and instalments retry on a schedule, and on a different provider when one keeps declining. The invoice gets paid without anyone chasing it.
03 Checkout
No website needed.
A payment link on WhatsApp, a QR on the counter, or the drop-in checkout. Mobile money and cards work on day one.
WhatsAppQR codeMobile moneyCards
04 Dashboard
Every provider, one screen.
Payments, routing decisions, webhooks and provider health in one place, in test and live mode. Workflows can run the moment a payment lands.
(03) Every screen
Built for the phone the customer is holding.
Desktop 1440
Mobile 390
Same product, same checkout, desktop and phonereevit.io, live
(04) How the routing works
One charge. Two providers. One tap.
No code change,
nothing asked of the customer
Illustrative · one charge, mobile money
CheckoutCustomer taps PayMoMo · GHS
Reevit RouterChain: Paystack → Hubtel
Provider 1PaystackNo response
Provider 2HubtelApproved
Webhookpayment.succeededTo your server
- 01charge.created
- 02route → paystack
- 03paystack · no response
- 04failover → hubtel
- 05hubtel · approved
- 06webhook · payment.succeeded
Under the hood · 01
Health-checked routing
Real-time provider health checks decide the fallback order, so a charge skips a provider that is already struggling.
02
Fraud rules first
Merchant-level rules for country, amount limits and BIN blocklists run before a charge leaves.
03
Envelope encryption
Merchant keys are sealed with a data key wrapped by a KMS-managed key, decrypted in memory at call time and never logged.
04
Normalised webhooks
Every provider’s events arrive in one shape, so switching providers never rewrites business logic.
ProvidersPaystackHubtelFlutterwaveStripePawaPayMoolreMonnifyM-Pesa
(05) Where it stands
Live, and taking payments for its first merchants.
Product facts,
not performance claims
1Integration
One snippet. Every provider in the chain sits behind it.
8Providers supported
Across Ghana, Nigeria and Kenya, from Paystack to M-Pesa.
GHS0Held by Reevit
Money settles in the merchant’s own provider accounts. Always.
2minTo connect Paystack
Paste the keys, add a fallback, take a live payment.
Live · early merchants
Designed, built and run by one person, from the dashboard to the key management.
Next on the roadmap
- Bring your own keys Planned
- Custom email and SMS notifications Planned
- Slack and Teams alerts Planned
- Post-payment actions Planned
Why it exists
Not glamorous. Just useful. And sometimes, that’s all innovation really needs to be.
Felix YeboahFounder, Reevit · from the launch post
Next project02 / 15
Miss Cookie Spices
All work15 projects