Why We Built a Payment Orchestrator From Scratch

If you have ever tried to accept payments globally, you know the pain. Stripe covers cards in 46 countries. PayPal works in 200+ but excludes most of Africa. Mobile money -- the dominant payment method for over 500 million people -- requires separate integrations with MTN MoMo, Orange Money, Wave, M-Pesa, and dozens of regional providers. Each provider has its own API, its own authentication flow, its own webhook format, and its own settlement schedule.

We built 0fee.dev to solve this problem once and for all: one API, one SDK, one dashboard -- and you cover the world.

The Problem: Payment Fragmentation

Consider this scenario. You are building a SaaS product in 2026. Your customers are in the United States, France, Nigeria, Kenya, and Ivory Coast. Here is what your payment integration looks like without an orchestrator:

That is five separate integrations, five different API contracts, five webhook handlers, five reconciliation processes. And we are only covering five countries. Scale that to 50 countries across four continents and you are looking at months of integration work, an entire team dedicated to payment maintenance, and a fragile system where one provider's API change can break your checkout flow.

What a Payment Orchestrator Does

A payment orchestrator sits between your application and the payment providers. It exposes a single, unified API that abstracts away the complexity of routing transactions to the right provider based on country, currency, payment method, and availability.

Your Application
       |
       v
   0fee.dev API (single integration)
       |
       +---> Stripe (cards, global)
       +---> PayPal (wallets, global)
       +---> Hub2 (mobile money, Francophone Africa)
       +---> PawaPay (mobile money, 21+ African countries)
       +---> Paystack (Nigeria, Ghana)
       +---> Flutterwave (30+ African countries)
       +---> BUI (West Africa)
       +---> PaiementPro (West Africa + cards)
       +---> ... 45+ more providers

When your customer in Ivory Coast wants to pay with Orange Money, 0fee routes the transaction to Hub2 or PaiementPro. When your customer in the US pays with a Visa card, 0fee routes to Stripe. Your code does not change. Your webhook handler does not change. Your reconciliation dashboard shows everything in one place.

The Vision: Five Lines of Code

From the beginning, we wanted the developer experience to be absurdly simple. Install the SDK, configure your API key, and start accepting payments worldwide:

typescriptimport { ZeroFee } from 'zerofee';

const zf = new ZeroFee({ apiKey: 'zf_live_...' });

const payment = await zf.payments.create({
  amount: 5000,        // $50.00 in cents
  currency: 'USD',
  country: 'US',
  method: 'PAYIN_CARD',
  customer: {
    email: '[email protected]'
  },
  returnUrl: 'https://yourapp.com/thank-you'
});

// payment.checkoutUrl -> redirect customer
// payment.id -> track status via webhooks

The same code structure works whether the customer is paying with a credit card in New York, a bank transfer in Lagos, or Orange Money in Abidjan. The only things that change are country, currency, and method.

For mobile money payments in Africa, it looks like this:

typescriptconst payment = await zf.payments.create({
  amount: 10000,       // 10,000 XOF
  currency: 'XOF',
  country: 'CI',       // Ivory Coast
  method: 'PAYIN_ORANGE_CI',
  customer: {
    phone: '+2250700000000'
  },
  returnUrl: 'https://yourapp.com/thank-you'
});

The customer receives a push notification on their phone, confirms the payment with their PIN, and the transaction settles. Your webhook fires with a standardized payload regardless of which provider processed the payment.

Multi-Tenant Architecture

0fee is not just a payment gateway -- it is a multi-tenant orchestration platform. Each application registered on 0fee gets:

• Isolated credentials: your Stripe keys, your PawaPay keys, your Hub2 keys -- stored encrypted, never shared across tenants.
• Custom routing rules: define which providers handle which countries for your specific use case.
• Separate webhook endpoints: each app configures its own callback URLs.
• Independent rate limits: one tenant's traffic spike does not affect another.
• Per-app analytics: revenue, success rates, provider performance -- all scoped to your application.

The architecture supports this through a hierarchical data model:

Organization (your company)
  └── Application (your product)
       ├── Provider Credentials (encrypted)
       ├── Routing Rules
       ├── Webhook Endpoints
       ├── API Keys (live + test)
       └── Transactions
            ├── Payments
            ├── Payouts
            └── Refunds

This means a single organization can run multiple applications -- a SaaS product, a marketplace, and an e-commerce store -- each with its own payment configuration, all managed from one dashboard.

Why Not Use an Existing Solution?

We evaluated every major payment orchestration platform before building 0fee. Here is what we found:

The gap was clear. No existing orchestrator treated Africa as a first-class market. Mobile money was either unsupported or bolted on as an afterthought. And the enterprise solutions required sales calls, lengthy onboarding, and pricing that excluded startups and small businesses.

The Numbers

After 86 development sessions spanning 80 days, here is what 0fee covers:

• 53+ payment providers integrated and tested
• 200+ countries with at least one payment method available
• 117 payment methods across cards, mobile money, bank transfers, wallets, and crypto
• 40+ currencies including XOF, XAF, KES, NGN, GHS, TZS, UGX, ZAR, and all major fiat currencies
• 7 SDKs available: TypeScript/JavaScript, Python, PHP, Ruby, Go, Java, and C#
• 90+ API endpoints covering payments, payouts, refunds, webhooks, analytics, and administration

The Routing Engine

At the heart of 0fee is the routing engine. When a payment request comes in, the engine evaluates:

1. Country: which providers are available in the customer's country?
2. Payment method: which providers support the requested method (card, mobile money, bank transfer)?
3. Currency: which providers can process the given currency?
4. Provider health: what is each provider's current success rate and latency?
5. Cost: which provider offers the lowest processing fee for this transaction?
6. App preferences: has the merchant configured provider priorities or exclusions?

The engine scores each eligible provider and selects the optimal one. If the primary provider fails, the engine automatically retries with the next-best provider -- this is called intelligent failover.

python# Simplified routing logic
async def route_payment(request: PaymentRequest, app: Application) -> Provider:
    eligible = await get_eligible_providers(
        country=request.country,
        method=request.method,
        currency=request.currency,
        app_id=app.id
    )

    scored = []
    for provider in eligible:
        score = calculate_score(
            success_rate=provider.metrics.success_rate_24h,
            latency=provider.metrics.avg_latency_ms,
            cost=provider.fee_schedule.get_fee(request.amount),
            priority=app.routing_rules.get_priority(provider.id)
        )
        scored.append((provider, score))

    scored.sort(key=lambda x: x[1], reverse=True)
    return scored[0][0]

This routing engine is what transforms 53 separate payment providers into one cohesive payment platform.

What Is Coming Next in This Series

This article sets the stage. In the articles that follow, we will go deep into:

• The Africa payment problem -- why mobile money is fundamentally different from card payments and why most orchestrators get it wrong.
• The complete provider map -- every provider, every country, every payment method, with code examples.
• Architecture decisions -- why we chose Python, FastAPI, SolidJS, and SQLite (and what we would change).
• Building from Abidjan -- the story of 86 sessions, one CEO, one AI CTO, and zero human engineers.

The payment infrastructure gap is real, especially for businesses that need to operate across Africa and the rest of the world simultaneously. We built 0fee to close that gap.

This article is part of the "How We Built 0fee.dev" series. 0fee.dev is a payment orchestrator covering 53+ providers across 200+ countries, built by Juste A. GNIMAVO and Claude from Abidjan with zero human engineers. Follow the series for the complete build story.