The choice underneath every 'accept payments' project
When a business decides to accept payments online or in an app, there is a fork in the road that often goes unnoticed until later: use an aggregator, or integrate the rails directly.
An aggregator - a payment gateway - lets you accept M-Pesa, cards, and sometimes bank transfers through one integration and receive one combined settlement. Direct integration means wiring each provider yourself: M-Pesa's Daraja, a bank's API, a card acquirer. Both are valid. Choosing without understanding the trade-off is how businesses end up overpaying on fees or over-building infrastructure they did not need.
What a gateway gives you
The appeal of a gateway is that it collapses a lot of complexity into one relationship.
- One integration instead of several - M-Pesa, cards and banks behind a single API.
- One settlement and one reconciliation stream, rather than money arriving from many sources.
- Card acceptance without carrying the heavy PCI-DSS burden yourself.
- Faster launch - days or weeks, not a multi-provider build.
- The provider absorbs a lot of the reliability, compliance and rail-specific quirks.
- Access to methods you would not integrate individually, like several banks or wallets at once.
What a gateway costs you
That convenience is not free, and the cost is recurring. A gateway takes a percentage or fixed fee on every transaction, forever. On top of that you give up some control: the checkout experience is partly theirs, the data passes through them, settlement timing is on their schedule, and you are exposed to their uptime and their decisions.
At low and moderate volume, none of this matters much - the fees are small and the time saved is large. The calculation changes as you scale. A few percent on a large monthly payment volume can quietly become one of your biggest line items, paid to a middleman for something you could operate yourself.
What direct integration gives you - and demands
Going direct means integrating each rail yourself: M-Pesa via Daraja, a bank via its API, cards via an acquirer or a card-only gateway.
The upside is lower cost per transaction - you pay only the rail's own tariff, not an aggregator's margin - and full control of the flow, the data, and the customer experience. The demand is engineering: you build and maintain each integration, handle their callbacks, reliability, reconciliation and go-live processes yourself. For a business where payments are core and volume is high, that investment pays back. For one just trying to take a few payments, it is overkill.
The volume math that usually decides it
Strip away the theory and it often comes down to arithmetic. Estimate your monthly payment volume, apply the gateway's percentage, and compare that annual figure to the one-off cost of a direct integration plus its ongoing maintenance.
At low volume, the gateway fee is a rounding error and building direct would be wasteful. At high volume, the gateway fee can dwarf the cost of building direct, and every month you delay is money handed to the aggregator. Somewhere between those is your crossover point. Knowing roughly where it sits turns this from a gut decision into a business one - and it is usually the reason growing businesses eventually bring their biggest channel in-house.
The answer is often 'both'
This is rarely all-or-nothing. A very common and sensible setup is a gateway for cards and less-common methods - where direct integration is genuinely painful - and a direct M-Pesa integration for the channel that carries most of your volume.
The way to keep this flexible is architectural: put every payment provider behind one internal interface in your system, so your application asks 'take this payment' without caring whether M-Pesa, a bank or a gateway fulfils it. Then you can add, drop or switch providers as your volume and costs evolve, without rewriting your app each time.
How Upeosoft helps you decide and build
We start with your numbers - volume, channel mix, growth - and tell you honestly whether a gateway, direct integration, or a blend serves you best, rather than defaulting to whichever is easiest to sell. Then we build it behind a clean provider-agnostic layer, so your payment stack can evolve as you grow without a rewrite.
If you are choosing a gateway, outgrowing one, or want to bring your highest-volume channel in-house, talk to Upeosoft and we will design a payment setup that fits your economics, not just your launch date.
