Paystack vs Flutterwave: A Technical Integration Guide for Nigerian Software Products | Blog

# Paystack vs Flutterwave: A Technical Integration Guide for Nigerian Software Products

TL;DR: Paystack wins on documentation clarity, webhook simplicity, and speed-to-ship for standard NGN payment flows; Flutterwave wins on multi-currency reach and payout rail breadth once you need to move money beyond Nigeria — most serious products end up integrating both.

If you're building a SaaS product, marketplace, or fintech feature for the Nigerian market, "which payment gateway should we use" is rarely a business question — it's an engineering question. Paystack and Flutterwave both sit on top of the same underlying rails (NIBSS, card networks, USSD), both are licensed Payment Solution Service Providers under CBN's framework, and both will get a NGN transaction from a customer's card to your bank account. The differences that matter show up in the API contracts, the webhook reliability, the settlement mechanics, and how much custom reconciliation logic you'll have to write to keep your ledger honest.

This guide is written for the person who has to actually implement the integration, not the person deciding on pricing tiers.

Provider Basics: Who You're Actually Building Against

Both companies are Nigerian-born payment infrastructure providers regulated by the Central Bank of Nigeria. Paystack (acquired by Stripe in 2020) has stayed narrower in scope — cards, bank transfers, USSD, mobile money, and virtual accounts, mostly optimized for NGN with an increasingly usable base for a handful of other African currencies. Flutterwave has pushed further into pan-African and cross-border rails, supporting mobile money across more markets, multi-currency collection, and its own payout/send-money product (Flutterwave Send).

For a product whose customers are overwhelmingly paying in Naira, both are viable. The decision starts to diverge once you need multi-currency settlement, marketplace payouts to many recipients, or card acquiring outside Nigeria.

Fee Structures: What You're Actually Passing On (or Absorbing)

Fees change periodically on both platforms, so treat this as a snapshot to validate against the live pricing pages before you finalize a pricing model that passes fees to users.

	Paystack (local NGN)	Flutterwave (local NGN)
Card/bank transfer fee	1.5% + ₦100, capped at ₦2,000; fee waived on transactions ≤ ₦2,500	2% (1.4% processing + 0.6% platform fee), capped at ₦2,000
International cards	3.9% + ₦100, no cap	Higher blended rate, varies by card scheme
VAT on fees	7.5% VAT applied on the processing fee	7.5% VAT applied on the processing fee
Payout/transfer fee	Tiered flat fee per transfer	₦25 + 7.5% VAT (₦5,001–₦50,000) up to ₦50 + 7.5% VAT (above ₦50,001)
Stamp duty	₦50 stamp duty on balance transfers ≥ ₦10,000 (effective Feb 2026)	Not applicable to the same balance-transfer flow
Monthly/setup fees	None	None

Both charge per-successful-transaction with no monthly minimums, which matters for early-stage products where predictable fixed costs aren't yet justified. Flutterwave's local NGN rate moved from a lower flat structure to the current 2% blended rate as of April 2025, which is a useful reminder: don't hardcode fee percentages into your pricing calculator — pull them from a config value you can update, or better, calculate the actual fee from the provider's transaction response rather than assuming a rate.

API and Webhook Architecture

This is where the day-to-day developer experience really diverges.

Paystack uses a REST API with predictable resource naming (/transaction/initialize, /transaction/verify/:reference, /customer, /subaccount) and signs webhook payloads with HMAC SHA-512, delivered in the x-paystack-signature header. You verify by hashing the raw request body with your secret key and comparing digests — a well-trodden pattern most backend frameworks handle in a few lines.

Flutterwave also exposes a REST API (v3) with a broader surface area — reflecting the wider product set — and verifies webhooks using a static verif-hash value you configure in the dashboard and compare against the verif-hash header on incoming requests. It's a simpler mechanism than HMAC signing but marginally weaker: a static secret string is more exposed to accidental leakage in logs than a computed HMAC digest, so treat that hash with the same care as an API key.

Practical implementation pattern for both:

1. Initialize the transaction server-side (never client-side) so you control the amount and reference.

2. Redirect or render the provider's inline checkout with the returned authorization URL / public key.

3. On redirect back, treat the client-side result as advisory only — the transaction is not confirmed until you either call the provider's verify endpoint or receive and validate a webhook.

4. Use the webhook as your source of truth for order fulfillment, and make the handler idempotent — both providers can retry webhook delivery, and your endpoint needs to safely no-op on a duplicate event ID or reference.

5. Always re-verify amount and currency server-side against what you initialized — never trust the amount in the webhook payload alone, to prevent tampered client requests from marking under-paid orders as fulfilled.

Common integration bugs we see in the wild map almost exactly to skipping steps 3–5: teams mark an order "paid" on the client-side redirect, or trust an unverified webhook, and end up with a reconciliation nightmare when a transaction fails after redirect or a webhook is spoofed.

Split Payments and Marketplace Payouts

If you're building a marketplace, booking platform, or any product that needs to split a single transaction across multiple recipients (platform fee + vendor payout), both providers support this natively rather than requiring you to build manual payout logic.

Paystack Transaction Splits let you define a split configuration (percentage or flat) tied to subaccounts, and Paystack settles each party's share into their own bank account on the same T+1/T+2 settlement cycle as the main account — no separate payout call required.
Flutterwave Sub-accounts work similarly: you configure a subaccount with a split ratio or flat deduction, and Flutterwave routes the settlement accordingly. One gotcha worth knowing at design time: if a subaccount is configured for a flat amount and the settlement is smaller than that flat amount, Flutterwave routes the entire settlement to the main account instead — an edge case that will silently break payout expectations if your reconciliation logic assumes the flat amount is guaranteed.

For either provider, build your own internal ledger table that records the expected split alongside the provider's transaction reference, and reconcile against the provider's settlement report on a schedule — don't rely on the split executing exactly as configured as your only source of truth, especially in the first few months of a new integration.

Regulatory Context: Why This Isn't Just an API Choice

Both Paystack and Flutterwave operate as licensed Payment Solution Service Providers (PSSP) under the CBN's payments framework, which means they can process and aggregate payments but cannot hold customer funds as a wallet the way a fully licensed PSP or MMO can. This matters for architecture: if your product needs to hold customer balances (a wallet, an escrow feature, a "top-up and spend later" model), you're building on top of a provider's rails but the compliance obligations for holding funds may sit with you, not just them — this is a conversation to have with legal counsel early, not after launch.

2026 is shaping up to be an active enforcement year for CBN's fintech policy stack — open banking rules, AML automation requirements, and updated cash/transfer policies are landing simultaneously, and payment providers are passing some of that compliance overhead through as new fees (the ₦50 stamp duty on Paystack balance transfers above ₦10,000, effective February 2026, is a direct example). Budget for fee structures to keep shifting, and isolate your fee-calculation logic so a provider policy change doesn't require a code deploy across your whole payments module.

Choosing Between Them for a Real Build

Pure NGN product, fast to ship: Paystack's tighter API surface and clearer webhook signing tend to mean less integration time and fewer edge cases to handle.
Multi-currency or pan-African ambitions: Flutterwave's broader payout and currency support reduces the number of providers you'll eventually need to stitch together.
Marketplace with payouts to many vendors: Both support splits; model the settlement edge cases (like Flutterwave's flat-amount fallback above) before you commit.
Uncertain / hedging: A growing number of Nigerian products integrate both behind a provider-agnostic payment abstraction layer, routing by currency, corridor, or fallback logic — more upfront engineering work, but it removes a single point of failure if one provider has an outage or a policy change breaks your flow.

Whichever path you choose, the integration work is rarely "call the API and done" — it's webhook reliability, idempotency, reconciliation against settlement reports, and staying current with a regulatory environment that's actively moving. This is the kind of integration work our team at Wise Hustlers handles regularly for clients building fintech and marketplace products across Nigeria and beyond — if you'd rather have engineers who've shipped this exact stack handle the payments layer, our API integrations service covers Paystack, Flutterwave, and the broader rails around them.

FAQ

Can I use both Paystack and Flutterwave in the same product?

Yes, and many Nigerian products do — typically behind an internal payment abstraction layer that routes transactions by currency, payment method, or as a failover if one provider has downtime. It adds engineering overhead (two sets of webhooks, two reconciliation flows) but removes a single point of failure.

Which one settles funds faster?

Both generally settle on a T+1 basis for standard NGN transactions, though exact timing can vary by transaction type, volume tier, and account status with each provider. Confirm current settlement SLAs directly with your account rep, since these terms can change with volume and negotiated agreements.

Do I need a PSSP license to accept payments through Paystack or Flutterwave?

No — that's the point of integrating with a licensed PSSP. Paystack and Flutterwave hold the CBN licensing so merchants can plug into their APIs without becoming licensed payment providers themselves. You only need to think about additional licensing if you're building something that holds customer funds as a wallet or moves beyond simple payment collection.

How do I handle a webhook that arrives before the user is redirected back to my app?

Design for this from day one — webhooks and redirects are not guaranteed to arrive in order. Your order/payment status update logic should live in one idempotent function triggered by whichever event (webhook or verified redirect) arrives first, with the second arrival safely treated as a no-op.