Payment Gateway Redundancy, Failover & Multi-Provider Architecture

In emerging African software markets, payment provider downtime, bank network outages, and switch failures directly impact business revenue. Operating a single payment gateway creates a single point of failure.

However, implementing multi-gateway redundancy (e.g. routing between Paystack, Flutterwave, and Monnify) is not simply a matter of catching HTTP exceptions and retrying requests against a secondary gateway. Doing so without strict transaction isolation creates severe double-charging risks and reconciliation chaos.

---

1. The Myth of Automatic HTTP Failover

Consider what happens if your application attempts to charge a card via Provider A, encounters a 10-second HTTP timeout, and automatically fails over to Provider B:

Application ──→ Initialize Charge (Provider A) ──→ Network Timeout (10s)
     │
     └──(Catch Timeout)──→ Initialize Charge (Provider B) ──→ SUCCESS
                                │
   (30 seconds later: Provider A actually processed the original request!)
                                │
                       DOUBLE-CHARGE OCCURS!

[!CAUTION] An HTTP timeout or gateway 5xx error does NOT mean the payment failed. The bank switch may have successfully debited the customer’s account before the gateway’s response timed out. Never switch gateways on the same payment attempt without verifying transaction status first.

---

2. Multi-Gateway Architecture Patterns

There are two safe architectural patterns for payment gateway redundancy:

Pattern A: Pre-Checkout Smart Routing (Static / Health-Based)

Determine the optimal gateway BEFORE presenting the checkout screen to the user based on real-time uptime monitoring, payment channel (e.g., DVA vs Card), and fee benchmarks.

graph TD
    A[Customer Initiates Checkout] --> B[Payment Orchestrator]
    B --> C{Check Gateway Uptime & Channel}
    C -->|Paystack Healthy| D[Route to Paystack API]
    C -->|Paystack Degraded| E[Route to Flutterwave / Monnify API]
    D --> F[Generate Isolated Paystack Reference]
    E --> G[Generate Isolated Alternate Reference]

Pattern B: User-Driven Alternative Selection

If an initial checkout attempt fails explicitly (e.g., card declined or user cancels), allow the customer to explicitly select an alternative payment method or provider for their next attempt.

---

3. Key Architectural Requirements for Multi-Provider Systems

1. Isolated Provider Transaction References

Never share reference strings across different providers. Use structured, provider-prefixed references:

• paystack_tx_20260822_9f81a7b
• flutterwave_tx_20260822_3k82b9c
• monnify_tx_20260822_7m10x4d

2. Provider Capability Mapping

Different gateways have differing rails, fee caps, and verification parameters:

• Paystack: Domestic cards (1.5% + ₦100, ₦2,000 cap), DVA (1% capped at ₦300).
• Flutterwave: Domestic cards (2.0% flat, no fixed fee).
• Monnify: Bank transfer / DVA (1.5% capped at ₦500).

Your orchestration layer must model these fee structures dynamically (e.g., using Tofali’s Fee Calculation Domain) before routing transactions.

3. Unified Webhook Ingestion Router

Direct webhooks from each provider to dedicated, isolated endpoints (/api/webhooks/paystack, /api/webhooks/flutterwave, /api/webhooks/monnify) that perform provider-specific signature verification before dispatching to a unified domain event bus.

---

4. Multi-Gateway Reconciliation & Ledger Design

Reconciliation across multiple providers requires normalized transaction state records:

namespace Tofali.Payments.Orchestration;

public sealed record NormalizedPaymentRecord(
    Guid InternalOrderId,
    string ProviderId,            // "paystack", "flutterwave", "monnify"
    string ProviderReference,      // Provider-specific reference
    long GrossAmountInMinorUnits,
    long FeeAmountInMinorUnits,
    long NetAmountInMinorUnits,
    string Status,                // Normalized status: Completed, Failed, Pending
    DateTimeOffset Timestamp
);

---

5. Summary Checklist for Payment Redundancy

• No Blind Retries Across Gateways: Always poll/verify Provider A’s verification API before attempting a secondary charge on Provider B.
• Reference Isolation: Prefix internal references with the provider ID to guarantee global uniqueness.
• Independent Webhook Endpoints: Separate signature verification logic for each provider.
• Unified Fee Modeling: Model net merchant settlements accurately across different gateway pricing rules.

---

6. Official Gateway References

• Paystack Developer Documentation: https://paystack.com/docs/api
• Flutterwave Developer Documentation: https://developer.flutterwave.com/docs
• Monnify Developer Documentation: https://docs.monnify.com
• Last Tested Date: August 22, 2026 UTC