Most ecommerce platforms in Kenya support M-Pesa. They built a card-first checkout, then bolted M-Pesa on as one option among several. The default is still cards. The receipts are still cards. The reconciliation flow is still cards. M-Pesa lives in a corner of the product, accessible but not primary.
We did the opposite. We started with M-Pesa as the primitive and worked outward. The default checkout is M-Pesa. The receipt template, the delivery flow, the daily Pulse brief, the refund process, every surface of the platform was designed for an M-Pesa transaction shape first. Cards are an option we will add later if a merchant asks for it. That single choice changed every other choice we made.
What "M-Pesa-first" actually means
M-Pesa-first is not a checkout toggle. It is a design philosophy. Five concrete examples of how it shows up in our codebase:
- The customer sees one button. Not three payment options behind a dropdown. One button: "Pay with M-Pesa." The customer enters their phone number, receives the STK push prompt, enters their PIN. Order paid in about 12 seconds median.
- The merchant sees the M-Pesa receipt as the source of truth. Every order page leads with the M-Pesa receipt number (QGH7H29K1L) instead of a generic transaction ID. The merchant uses this number to reconcile with their Paybill or Till statement.
- Money lands directly in the merchant's Paybill. Not in our account. Not in a sweep account. Daraja runs against the merchant's own credentials, which we encrypt at rest with pgsodium. We never custody funds. The merchant has a real relationship with Safaricom, not an aggregator-mediated one.
- Refunds use the M-Pesa flow. Refunds reverse via B2C, hitting the customer's phone within seconds. Not a 5-day card-network rollback. Not a manual store credit.
- Reporting aligns to East Africa Time. Yesterday means yesterday in Nairobi, not yesterday in UTC. Our daily Pulse brief runs against EAT day boundaries so the 11pm Saturday sale shows up in Saturday's numbers, not split across Sunday at 2am.
Why most platforms in Kenya are still card-first
Three reasons, none of them malicious, all of them historical:
One. The platforms were built by teams trained on Stripe, Shopify, and WooCommerce. Those tools assume the customer has a card. The mental model travels with the engineer. A team that defaults to "add Stripe later" is a team that designs everything else around card primitives.
Two. The aggregators (Pesapal, IntaSend, Flutterwave) built generic payment gateways that abstract over both cards and mobile money. Their incentive is to look the same in every market. From their position, M-Pesa is one option in a long list. From a Nairobi merchant's position, M-Pesa is the rail; everything else is a backup plan.
Three. Investors and accelerators pattern-matched Kenyan ecommerce to American ecommerce. The pitch deck said "Shopify for Africa." The product was built to look like Shopify, which is card-first because America is card-first.
We respect those tools. We also think they leave the door open for a platform that takes the local rail seriously from line one.
What changes when M-Pesa is the primitive
Once you commit to M-Pesa-first, four downstream design decisions get easier:
Customer onboarding is shorter. No card details to capture. No 3D Secure flow. No saved-card vault to maintain. The phone number is the customer identity. The phone number is the receipt delivery channel. The phone number is the refund destination. One primitive does the work of four.
Fraud is structurally lower. M-Pesa transactions are irreversible from the customer side once the PIN is entered. The merchant cannot be charged back. Cards are reversible for 90 to 180 days depending on the network. M-Pesa-first merchants run with meaningfully lower fraud exposure, which means they keep more of their margin.
Reconciliation is honest. The merchant sees the same receipt number on our platform, on the customer's phone, on the M-Pesa statement, and on their Safaricom dashboard. One identifier across all four surfaces. No reconciliation tax.
International expansion has a clear pattern. The same design discipline ports to mobile-money-strong markets. In Tanzania the button says Pay with M-Pesa TZ. In Uganda it says Pay with MTN Mobile Money. The primitive shifts; the design philosophy holds. A card-first platform expanding into mobile-money markets has to rebuild every surface; an M-Pesa-first platform changes one adapter and ships.
The trade-offs we accepted
M-Pesa-first is not free. Three trades we made consciously:
One. We lost the merchants who really do need cards. Hotels, international ticket vendors, B2B SaaS sellers. Those are not our customers and we are at peace with that.
Two. The Daraja API is harder to operate than Stripe. Daraja access tokens expire every hour. Callbacks sometimes do not arrive. The sandbox approval process is slower than developers raised on Stripe expect. We absorbed that complexity so the merchant does not have to. (We wrote a separate post on the engineering details.)
Three. Some early customers asked "but what about cards?" in the first 30 seconds of every onboarding call. We answered honestly: most of your customers will not use cards anyway; we will add cards later if the demand is real. Most merchants accepted that. A few did not. They went to Pesapal. We learned, over time, that the merchants who stuck with us were happier than the merchants who chose card-first. That is the validation that mattered.
What this means for our roadmap
The four Angazé tools (Stack, Forge, Pulse, Marketplace) all inherit the M-Pesa-first discipline. Stack is the obvious one. Pulse's daily brief reports M-Pesa receipts in EAT-aligned days. Marketplace ranking includes verified M-Pesa transactions as a quality signal. Forge sites can drop in an M-Pesa checkout widget without ever touching cards.
When we ship the Daraja Checkout Button later this quarter, it is the same discipline taken to its logical conclusion: any website on the Kenyan internet can drop in one snippet and accept M-Pesa exactly the way Stack does internally, with the same atomic stock decrement, the same idempotent callback, the same EAT-aligned receipts.
The bigger bet
The bigger bet underneath all of this is that the future of commerce in growth markets is mobile-money-native, not card-native. The operating system that wins in Kenya will not be a Kenyan adaptation of Shopify; it will be a system designed from line one for the WhatsApp-and-M-Pesa-native operator. We think that operator is being underserved today, and we are building Stack to serve them specifically.
If you are a Kenyan operator running on cards-first infrastructure and the friction is wearing on you, talk to us. If you are running on WhatsApp + Paybill spreadsheets and you want the operating layer that organises all of it, also talk to us. We are personally onboarding the first 50 Stack merchants. After that the rest of the cohort gets in through the same door, but the lifetime founding-50 pricing closes.
From invisible to inevitable.