01
Core layerConnect
One integration in front of every provider.
Add Paystack, Flutterwave or a new rail without touching your product code. Credentials, environments and provider configuration live in one place instead of five.
Early access · Building with design partners
Your first payment provider was a decision. Your fourth is a system nobody owns.
Payment infrastructure, without the complexity.
Quirk gives technology companies one unified layer to connect, manage, monitor and scale their payment infrastructure. One integration in front of Paystack, Flutterwave and every rail you add after them.
Not a payment provider · Not a new rail · A layer above the ones you already use
POST /v1/paymentsRouted by Quirk
- 00.000quirk.payments.createOne call. Provider not specified.
- 00.412route → provider_aDeclined upstream. Issuer timeout.
- 00.907route → provider_bAuthorised. Same request, no code change.
- 00.913event: payment.succeededNormalised shape. One schema across providers.
Illustrative trace. The SDK is the starting point, not the product.
What growth does to payments
Nobody sets out to build payment infrastructure. It accumulates.
Payments start as one integration and end as a system with no owner. These are the five points where it stops being a feature and becomes infrastructure.
- 01
One provider quietly becomes four
You add a second for coverage, a third for a payout rail, a fourth because a market demanded it. Each arrives with its own SDK, its own webhook shape, its own dashboard and its own edge cases, and all four now live inside your codebase.
- 02
Failed transactions turn into guesswork
A payment fails and nobody can say why with confidence. Issuer, provider, network, or your own retry logic. The failure is measurable, the reason is not, so the answer becomes a support thread instead of a query.
- 03
Reconciliation becomes someone's full-time job
Every provider settles on its own schedule, in its own format, with its own fee structure. Finance rebuilds the same spreadsheet every month to answer a question your systems should already know.
- 04
Every new payment method is a new release
Mobile money, bank transfer, USSD, cards, wallets. Each one is a sprint, a migration and a fresh set of failure modes, long after the commercial decision to support it was made.
- 05
Expansion multiplies everything at once
A new market means a new provider, new methods, new currency handling and new compliance. Complexity stops adding and starts compounding, and the payments layer becomes the thing that slows the roadmap.
At that point the problem is no longer which provider to use. It is that nothing sits above them.
Where Quirk sits
Between your application and every provider you use.
Quirk is not another payment API competing with Paystack or Flutterwave. It is the layer above them, so your product talks to one interface while your money moves across many.
Layer 01
Your application
- Checkout
- Payouts
- Subscriptions
- Wallets
- Refunds
Layer 02 · Control layer
Quirk
- Connect
- Normalise
- Route
- Monitor
One interface, one data model, one operational view. Your team stops writing provider-specific code and starts making provider decisions.
Layer 03
Providers and rails
- Paystack
- Flutterwave
- Card networks
- Bank transfer
- Mobile money
- Your next provider
One integration, not one per provider
You build against Quirk once. Adding, replacing or splitting traffic across providers stops being a release.
The SDK is the entry point
The SDK is how your code reaches the layer. The layer itself is the routing, the normalised data model and the operational view around it.
Your provider relationships stay yours
Quirk does not replace your providers or hold your contracts. It sits above them and gives you a single place to run them.
What the layer does
Connect, normalise, route, monitor. Then understand.
Four things Quirk is being built to do from day one, and one it is working toward. We would rather be clear about the difference than blur it.
02
Core layerNormalise
One data model across providers that disagree.
Payments, refunds, payouts and webhooks arrive in a single consistent shape, with provider quirks translated rather than pushed into your application logic.
03
Core layerRoute
Decide where a transaction goes, and change your mind.
Send traffic by method, market, currency, cost or availability. Retry a failed attempt on a second provider without a deploy, and shift volume as your commercial terms change.
04
Core layerMonitor
One operational view instead of four dashboards.
See transactions, failures, webhook delivery and provider health in one timeline, so an incident is something you observe rather than something a customer reports.
05
Planned · not liveUnderstand
Turn transaction history into decisions.
The layer that routes and records every payment is the layer that can eventually explain them. This is the direction Quirk is building toward, and it is not live today.
For the people who own this
The SDK is where you start. It is not the whole product.
A few lines get a payment moving. What matters afterwards is the routing you can change without a deploy, the events that arrive in one shape, and the record of every attempt behind them.
payments/create.tsIllustrative
import { Quirk } from '@quirk/node' const quirk = new Quirk({ apiKey: process.env.QUIRK_API_KEY }) // One call. Quirk selects the provider.const payment = await quirk.payments.create({ amount: 250000, currency: 'NGN', method: 'card', customer: { email: 'ada@marketplace.africa' }, reference: 'ord_8241'}) // Same shape, whichever provider handled it.payment.provider // 'flutterwave'payment.status // 'succeeded'payment.attempts // [{ provider: 'paystack', outcome: 'failed' }, ...]No provider name in your application code. Changing where that payment goes is a rule, not a release.
Documentation
Quickstart
First payment through the layer in one file.
Connecting providers
Credentials, environments and provider configuration.
Routing rules
Choose a provider by method, market, cost or availability.
Normalised objects
Payments, refunds, payouts and customers in one schema.
Webhooks and events
One event stream, delivered and retried consistently.
Failures and retries
Attempt history, failure reasons and fallback behaviour.
The full reference opens as we bring companies onto the layer. Join the waitlist and we will send it with your access.
Request accessWho this is built for
Technology companies where payments live inside the product.
Quirk is for African technology companies past their first integration, where payments have become an operational system rather than a single API call.
Marketplaces
Money comes in from buyers and goes out to sellers, often on different rails, often on different days.
Collections on one provider, payouts on another, and a ledger that has to agree with both.
Fintechs
Payments are the product, so every provider outage, decline and settlement delay is felt by your customers directly.
You need failover and attempt-level visibility, not a second dashboard.
Commerce platforms
You process on behalf of merchants who each want their own methods, their own provider and their own reporting.
One codebase, many payment configurations, and no clean way to manage them.
SaaS companies
Recurring billing across markets, currencies and methods that were never designed to renew cleanly.
Failed renewals you cannot explain and retries you cannot tune.
Embedded payments
Any technology business where payments sit inside the product rather than beside it.
Payments work is quietly taking engineering time away from your actual roadmap.
If payments are a system you operate, not a service you bought, Quirk is aimed at you.
You will recognise this if
- You integrate with more than one payment provider.
- A payment failure takes more than one person to explain.
- Reconciliation happens in a spreadsheet somebody maintains by hand.
- Adding a payment method or a market requires engineering work.
- No single person can say how payments are performing right now.
Where this is going
Moving payments is the first job. Understanding them is the next one.
A layer that routes and records every transaction is the only place that can eventually explain them. That is the direction Quirk is building in, and we want to be exact about what exists now and what does not.
Today
Connecting, normalising, routing and monitoring your payment infrastructure.
Not yet built
Explaining what those payments are telling you.
The questions we intend to answer
Roadmap · not available today- Why did this payment actually fail?
- Not a provider error code copied into a support ticket, but the attempt history behind it and what it has in common with the others.
- Where are customers dropping off?
- The point in a payment flow where people stop, by method, market and device, rather than a single conversion number at the end.
- Which provider is genuinely performing best?
- Success rates and latency compared for the same method, market and amount band, using your own traffic rather than a public promise.
- What is a transaction really costing you?
- Fees, retries and failed attempts counted together, so the cheapest provider on paper and the cheapest in practice can be told apart.
- What happens before a provider degrades?
- The patterns that show up in the minutes before failure rates move, so an incident becomes something you see coming.
None of this ships on day one, and we will not describe it as if it does. It is the reason the layer is worth building in the right order: connect first, normalise honestly, then earn the right to interpret.
The short version
Quirk is not another payment API. It is the control layer for companies whose payment infrastructure is becoming complex.
Your providers keep doing what they do well. Quirk gives you one place to run them, one shape for the data they return, and one view of what is actually happening to your money.
Early users and design partners
Quirk is early. If your payment infrastructure is getting hard to manage, that is exactly who we want to build with.
We are onboarding a small number of companies whose payments have outgrown a single integration. Not a beta list to sit on. A short group we work with directly while the layer takes its shape.
Access before general availability
You run real traffic through the layer while it is still being shaped, with the team on the other end of the line.
Influence over the model
The normalised objects, the routing rules and the failure taxonomy get decided with the companies actually living with them.
Terms that reflect building together
Design partners are not paying to be a test environment. Pricing and commitments match the stage we are both at.
What we ask in return
- A live payment setup with more than one provider or method.
- An hour every couple of weeks with someone who owns payments.
- Direct feedback, including the parts that do not work yet.
Prefer to talk first?team@quirk.dev
