Not every market runs on card-based checkout. Here's the architectural reasoning behind building a payment-state system instead of a payment gateway.
One of the earliest and most consequential architecture decisions we made was choosing not to build a payment gateway. Here's the reasoning, and why it turned out to be the right call for the market we're building in.
TheAssumptionMostSoftwareMakes
Most software built for commerce assumes a single, clean payment moment: the customer clicks "pay," a card is charged, and the transaction resolves instantly. This model works well in markets where card-based checkout is dominant.
It breaks down quickly in markets where payment happens through a mix of cash, bank transfer, mobile money, and card terminals — often outside the software entirely, and often not at the exact moment of ordering.
TheRealWorkflowWeNeededtoSupport
In the markets we're building for, a transaction might look like this:
None of this fits a traditional "charge card, get instant confirmation" model. Forcing it into that shape would mean rejecting how businesses in this market actually operate.
TheArchitecturalDecision
Instead of building a payment gateway — which would require becoming a licensed money-handling intermediary with all the regulatory and liability weight that carries — we designed the system around payment state tracking.
The system models payment as a lifecycle with clear, auditable states:
Each transition is logged, reviewable, and tied to evidence — a proof upload, a staff confirmation, a manual note. The platform never touches the money directly; it gives the business a reliable, auditable record of what happened around it.
WhyThisIsaBetterFit,NotaCompromise
It would be easy to frame this as a limitation — "we don't process payments" — but that framing misses the point. Payment processing is a solved problem with mature, specialized providers already built for it. What's not solved well is giving a business operating with mixed, informal payment methods a clean, structured way to track what's owed, what's paid, and what needs staff review.
By staying out of the money-movement business and focused entirely on state and visibility, the system stays lighter, easier to reason about, and genuinely useful in markets that don't fit the card-first assumption baked into most commerce software.
TheBroaderPrinciple
Good architecture isn't about building every capability a system could theoretically have. It's about being honest about what problem you're actually solving, and for whom. Sometimes the more valuable engineering decision is the boundary you draw, not the feature you ship.