Multi-gateway payment architecture (Wave + OM + Stripe): the 2026 pattern that ships

Once you cross 10M XOF/month volume, the aggregator margin (1%–2.5% of every transaction) becomes a critical cost line. A multi-gateway architecture lets you use PayDunya for XOF, Stripe for EUR, and direct Wave Business API to save on your #1 channel.

TL;DR

- Pattern: a PaymentRouter service that picks the gateway based on (currency, country, amount, availability).

- Benefits: −0.5% to −1.2% on fees, automatic fallback, unified reporting.

- Initial cost: ~2 weeks dev for v1, ROI <4 months if volume >10M.

Architecture diagram

`

[Frontend site]

↓

[PaymentRouter]

/ | \

↓ ↓ ↓

[Wave direct] [PayDunya] [Stripe]

\ | /

\ ↓ /

[PaymentEvents DB]

↓

[Unified reporting]

`

Code: PaymentRouter (TypeScript)

`ts

import { wavePay } from './gateways/wave';

import { paydunyaPay } from './gateways/paydunya';

import { stripePay } from './gateways/stripe';

interface PaymentRequest {

orderId: string;

amount: number;

currency: 'XOF' | 'EUR' | 'USD';

buyerCountry: string;

preferredMethod?: 'wave' | 'om' | 'card';

}

export async function routePayment(req: PaymentRequest) {

const { currency, preferredMethod } = req;

if (currency === 'EUR' || currency === 'USD') return stripePay(req);

if (preferredMethod === 'wave' && (await isWaveHealthy())) {

try { return await wavePay(req); }

catch (e) {

console.warn('[PaymentRouter] Wave direct failed, fallback PayDunya', e);

return paydunyaPay(req);

}

}

if (preferredMethod === 'om') return paydunyaPay(req);

return paydunyaPay(req);

}

async function isWaveHealthy(): Promise {

const cached = await redis.get('wave:health');

if (cached !== null) return cached === '1';

try {

const res = await fetch(${WAVE_API}/health, { signal: AbortSignal.timeout(2000) });

await redis.setex('wave:health', 30, res.ok ? '1' : '0');

return res.ok;

} catch {

await redis.setex('wave:health', 30, '0');

return false;

}

}

`

Real savings (Kolonell client case)

Premium fashion shop in Dakar, 18M XOF/month over 12 months:

→ ~1.92M XOF saved over 12 months for a 2.5M XOF initial investment. ROI = 7.6 months.

Unified reporting

All payment events route through a single PaymentEvent table regardless of provider:

`prisma

model PaymentEvent {

id String @id @default(cuid())

externalId String @unique

provider String

orderId String

amount Int

currency String

status String

payload Json

receivedAt DateTime @default(now())

@@index([orderId])

@@index([provider, status])

}

`

The admin dashboard aggregates: revenue per provider, success rate, real fees, mean latency. Required for ongoing arbitrage.

Multi-gateway pitfalls

• Reconciliation — each provider settles on its own clock (T+1, T+2, T+5). Build an expected_settlements view that crosses payments with daily expected bank balance.
• Webhook races — same payment rerouted (fallback) can produce two webhooks. Unique constraint on externalId + provider solves it.
• Sandbox tests — each provider has its sandbox. Maintain 3 key sets (.env), automate fixtures.

FAQ

Q: Maintenance cost?

A: ~5h/month for API updates + monitoring. Far below fee savings.

Q: How to choose default routing?

A: Follow data. If Wave is 65% of payments, Wave-first with PayDunya fallback. If Wave is 30%, stay 100% PayDunya.

Q: Can Stripe Connect orchestrate everything?

A: Yes for international marketplaces, no for most African SMEs (insufficient Wave/OM coverage). See our Stripe Connect marketplace guide →.

Conclusion

Multi-gateway isn't for everyone. Below 10M XOF/month, single aggregator wins (simplicity > marginal savings). Past that, the architecture above is now our Kolonell standard — it pays back inside 8 months and unlocks continuous optimization.