Payment Gateways in Nigeria: Providers, Costs, and How to Choose

To choose a payment gateway in Nigeria, start with the payment methods your customers use, your account eligibility, total fees, and settlement terms. Paystack, Flutterwave, Monnify, Interswitch, and Remita offer services worth comparing. The right choice depends on the specific product and contract, not the brand alone.

This guide compares Nigerian payment providers and explains the roles behind a payment, from transaction management to reconciliation and accounting. It also examines SDK.finance, a FinTech software provider, and how its software can help teams build merchant payment products around external gateways.

Five payment gateways in Nigeria compared

Use this shortlist to compare payment methods, business fit, and published commercial terms. Availability depends on the account and service you select. The fees below are starting points for evaluation, not a ranking.

Paystack

Paystack combines online checkout with developer APIs for stores and apps. It supports cards, transfers, and USSD in Nigeria, alongside recurring-payment tools. Dedicated virtual accounts add a way to identify payments from returning customers, making the service relevant to businesses combining checkout with repeat account-based collections. Recurring billing depends on the chosen channel, and international acceptance requires the appropriate account approval.

Flutterwave

Flutterwave combines online checkout, payment links, and invoices with separate payout services. This range suits businesses collecting through a website as well as shared links or invoices. Nigerian collection options include cards, transfers, and USSD. For international cards, its pricing page states that charging and settlement use local currency by default; a different settlement arrangement needs explicit confirmation.

Monnify

Monnify’s virtual accounts make it relevant to businesses where matching incoming transfers to customers is central to the payment flow. Card and USSD acceptance provide additional collection options. Monnify offers regular reserved accounts and invoice-linked accounts, with configurable handling of overpayments and underpayments. Check these settings alongside account activation, expiry, and customer verification requirements.

Interswitch

Interswitch Web Checkout offers an inline window on the merchant’s website or a redirect to its payment page. Its documentation lists cards, transfers, USSD, and wallets. The two integration routes give teams a choice in how customers enter checkout while using several payment methods through the service. Evaluate the contracted gateway product and its reporting, rather than assuming every capability of the wider Interswitch group is included.

Remita

Remita supports billing-led collections, where payments need to match a bill or customer obligation. Its APIs use a Remita Retrieval Reference, or RRR, to identify a payment and include recurring-payment services. This makes payment references and bill tracking central to its evaluation. For recurring collections, the customer mandate and cancellation process are as important as the initial payment experience.

Payment gateway fees and settlement in Nigeria

Compare providers using the amounts and payment methods your customers use. Include fixed charges, fee caps, taxes, currency conversion, and payout costs in your calculation.

Rates also vary by payment method:

• Paystack: dedicated virtual accounts cost 1%, capped at NGN 300. International payments cost 3.9% plus NGN 100.
• Flutterwave: international payments cost 4.8%, plus VAT on the fee.
• Monnify: bank transfers cost 1.5%, capped at NGN 2,000, excluding VAT.

Interswitch’s integration is free. Budget separately for your team’s development work, plugin maintenance, and any external implementation support.

Compare the same transaction amounts

For local card payments of NGN 2,000 and NGN 10,000, Paystack’s base fees are NGN 30 and NGN 250; Flutterwave’s are NGN 40 and NGN 200. Monnify and Interswitch IPG each charge NGN 30 and NGN 150. These calculations exclude separately applicable taxes and other charges. Request Remita’s channel-specific tariff; a directly comparable public rate was not confirmed.

Include these components in your monthly cost estimate:

• Expected transactions grouped by payment method, currency, and amount.
• Each channel’s percentage, fixed charge, and fee cap.
• Applicable taxes, conversion, payouts, and other contracted charges.

Confirm who bears the fees and whether collection fees are returned after a refund. Request Remita’s current collection terms and confirm that any quoted Interswitch rate applies to your selected gateway product and payment methods.

Check when funds become available

• Paystack: local settlement on the next business day.
• Flutterwave: local settlement on the next business day; international payments in Nigeria settle in five business days.
• Interswitch IPG: next-business-day settlement. Confirm the schedule for your contracted product.
• Monnify: same-day settlement by 10pm, including weekends and public holidays.

Check cut-off times, reserves, and exceptions in your agreement.

How to choose a payment gateway in Nigeria

Match the provider to your business model

Start with your business model, then test the workflow that matters most to it. Use the following scenarios to set your requirements before choosing a provider.

Accepting international payments

For international payments, check three things separately:

• Customer location: the countries and payment methods your account can accept.
• Charging currency: what the customer pays and whether conversion applies.
• Settlement currency and account: where your business receives the funds.

Accepting a foreign card does not automatically mean receiving US dollars. Confirm approval for your business category, conversion costs, and refund handling.

Choose how to connect: payment links, hosted checkout, or APIs

Choose the integration that gives you enough control without adding work your team cannot maintain. Payment links, hosted checkout, and APIs are ways to connect a payment flow; cards and transfers are payment methods.

• Payment links: share a provider-hosted page with little checkout development. This suits simple sales or invoices, but your team still needs to connect each payment to an order and manage refunds.
• Hosted checkout or a supported store plugin: connect a website while the provider collects payment details. Check compatibility with your CMS version, currencies, subscriptions, and refund process, as well as who maintains the plugin.
• APIs and SDKs: build a more customised customer journey and connect payment events to your product. This requires development, monitoring, and maintenance. APIs can still use hosted fields; collecting raw card data directly changes your security responsibilities.

Complete onboarding and agree security responsibilities

Ask the provider for the requirements that apply to your entity, business activity, and settlement account before committing to an integration. These may include business registration, ownership and identity checks, and a review of your website or service. Check the contracting entity in the CBN payment service provider register, and distinguish merchant onboarding from permissions needed to operate your own payment service.

Agree who handles sensitive payment data, access controls, incident response, and disputes. A hosted checkout can reduce the card data your application handles, but it does not remove all merchant responsibilities. Confirm the applicable PCI DSS validation with your provider or acquirer. Keep secret keys on the server, restrict production access, and follow the provider’s verification and webhook guidance.

Test the complete payment journey

When evaluating payment gateway software, test the complete journey from order creation to provider reports and bank records:

• Successful and failed payments: confirm that the order receives the correct status.
• Timeouts and duplicate notifications: verify that a retry cannot create a second charge or credit.
• Partial transfers and refunds: check the outstanding amount and the link to the original payment.
• Reporting and settlement: trace the references and amounts through to the bank entry.

Use these acceptance tests as the handover standard for your software team or systems integrator.

Measure payment performance after launch

Track the customer journey as well as the provider’s response. A customer who leaves checkout is different from a bank declining an attempted payment. Review results by method, provider, and device so an overall average does not hide a local problem.

• Checkout completion: paid orders as a share of checkout sessions, using a defined session window.
• Payment success: successful attempts as a share of attempted payments, with retries identified separately.
• Failure reasons: customer abandonment, bank declines, and technical errors where the available data distinguishes them.
• Settlement and support: actual time to receive funds, unresolved settlement differences, and time to resolve payment enquiries.

Use a consistent definition and reporting period for each measure. Establish a baseline from your own traffic and investigate changes instead of assuming a universal target suits every business.

Decide whether provider tools are enough

For a merchant accepting payments through one provider, the provider’s checkout, dashboard, and reports may be enough. The requirements change when your business serves multiple merchants or connects several payment providers. You then need a consistent way to manage merchant accounts, apply your own fees, track payment events, and explain differences between collections and settlements.

At that point, choosing a gateway is only part of the decision. You also need to define the software and operational controls around your selected providers.

How payments work in Nigeria

Payment processor vs payment gateway: who does what?

A gateway passes payment information from a website or app to payment services. Processing, routing, merchant acceptance, and internal record-keeping are related but distinct roles. One provider may perform several of them. Use the table to identify who owns each part of your flow.

These are technical roles, not licence categories. Contract scope determines which functions your provider performs.

Payment confirmation, settlement, and reconciliation

For a card payment, the issuing bank approves or declines the request through the relevant processing network. For a bank transfer, the customer sends funds to a collection account and the provider identifies the incoming payment. The two methods follow different paths, but both need records beyond the initial response.

Payment confirmation establishes the reported outcome. Settlement fulfils the financial obligations between the parties. Reconciliation compares your records with provider reports and bank entries. Track these separately so a successful checkout does not hide a missing settlement.

Nigerian transfer infrastructure

NIBSS Instant Payment, or NIP, supports real-time interbank transfers. NIBSS’s NPS guidance describes the National Payment Stack as separate infrastructure using ISO 20022 messaging and requiring its own integration. Ask your provider which service your payment flow uses; do not assume every participant has moved to NPS.

Cards, bank transfers, and USSD

Cards, bank transfers, and USSD offer different payment experiences. Cards let customers pay through checkout, while bank transfers can serve both online orders and business invoices. USSD uses short codes on a mobile phone and is an option where supported by the provider and bank.

Temporary and dedicated virtual accounts

A virtual account gives a customer bank details that help a provider identify an incoming transfer. A temporary account can be tied to a specific payment. It may expire after a defined period. A dedicated account can be assigned to a customer and used for further payments, subject to the provider’s rules.

When choosing between them, focus on account expiry, payer verification, and how your system handles late or unexpected transfers. Store the provider’s account and payment references against the relevant customer or invoice, then assess the amount actually received.

When the amount or timing does not match

Consider a simple example. A customer receives details for a NGN 10,000 invoice but transfers NGN 8,000. The account number may identify the customer correctly. Your system must still record a partial payment and keep the remaining NGN 2,000 visible. Marking the whole invoice as paid would hide an outstanding amount.

Late transfers need clear handling too. Confirm what the provider does when a temporary account expires, and define how your team will investigate an unexpected payment.

Managing multiple payment providers and financial records

The following controls matter when a marketplace, PSP, or FinTech product manages several providers, merchants, or balances. A single-provider store may rely on its provider’s dashboard. For a broader payment product, each new provider introduces references, statuses, reports, and contracts that your team must bring together.

Fragmented statuses and payment events

Your internal transaction ID may differ from the provider’s reference and the reference on a bank statement. Keep those identifiers linked so support and finance can trace the same payment. Status names also need mapping. “Pending” could mean waiting for customer action in one service and waiting for a final response in another.

Webhooks, the messages providers send when events happen, need careful handling. Validate their source and make repeated deliveries safe. If the same event arrives twice, it should not create a second credit. Follow each provider’s rules for webhook handling and server-side payment verification. A customer returning to a success page is not enough evidence on its own.

Do not automatically send a payment to another provider just because the first request timed out. First establish whether it succeeded. Otherwise, a retry could charge the customer twice.

Fees, refunds, and settlement exceptions

A NGN 10,000 collection may produce a smaller settlement because of fees, holds, or adjustments. Refunds and chargebacks add further events: a refund is initiated by the merchant, while a chargeback follows a card scheme’s dispute process. Link each event to the original transaction and record its effect on the merchant’s balance and settlement. A single “paid” flag cannot describe that history.

Transaction and merchant operations

Operations staff need searchable payment references, merchant records, and permissions that match their roles. Support may investigate a delay, while finance reviews a fee difference and an authorised colleague approves an adjustment. Keep an audit trail of those decisions, give unresolved cases a clear owner, and record the evidence used to close them.

Check that collected payments reach your bank account

Payment reconciliation checks that the payments you recorded match the provider’s report and the money received in your bank account. First, find each payment in the provider report using its reference, amount, and currency. Then check the provider’s payout against the bank statement. A provider may combine several payments into one deposit, so the bank statement alone cannot confirm every customer payment.

In this illustrative example, customers pay NGN 20,000. The provider deducts NGN 200 in fees, leaving NGN 19,800 to reach the bank account. Check the payment details and fees in the provider report, then match the payout amount and reference to the bank statement. Investigate any unexplained difference before marking the payout as reconciled.

A ledger that records the financial effect

A ledger records what a payment means financially. Depending on your business model, that may include an amount due from a provider, a fee expense, or an amount owed to a merchant. Double-entry accounting records balanced debit and credit entries. It gives finance a structured way to follow those changes.

The exact entries depend on your accounting policy and who owns the funds. A merchant accepting its own sales and a platform collecting for other merchants may need different accounting treatment. Agree the rules with your finance team and test reversals, refunds, and fee adjustments. The ledger records these effects; it does not move the funds.

Reference architecture: follow the money and the records

A useful architecture separates the external movement of money from the software that requests, tracks, and records it. For a broader view of these components, see our guide to payment system design.

This is an illustrative model. Account ownership, settlement paths, and integration scope depend on the agreed service. Card payments involve their own acquiring and scheme arrangements.

Build and scale your payment gateway with SDK.finance

If your payment product needs shared merchant workflows and financial records across providers, SDK.finance can provide part of that software foundation. Its Transaction Platform supports merchant accounts, configurable fees, and operational transaction records. Your team builds the checkout experience and integrates the selected payment providers. The General Ledger records the accounting effect of payment and settlement events under your defined accounting rules.

For example, your gateway may accept card payments through one provider and bank transfers through another. Your team defines the checkout experience and connects the selected services, while configuring merchant accounts, fees, and transaction records in SDK.finance. The relevant capabilities include:

• Manage merchants across your payment product: give merchants a portal to view transactions and balances, manage stores, and request withdrawals through your configured payment flow.
• Apply your merchant pricing: configure fixed or percentage fees and transaction limits by contract, operation, and currency. Set your merchant charges alongside the fees charged by your selected providers.
• Connect your selected payment providers: build integrations through APIs, webhooks, or middleware to exchange payment requests and status updates. Define and test payment methods, refunds, and error handling for each connection.
• Investigate differences in payment records: review provider transaction statuses and compare internal records with uploaded provider or bank files for closed operational periods. Resolve missing transactions and amount differences before closing a reconciliation case.
• Record the financial effect of each event: use the General Ledger to map collections, gateway fees, refunds, and settlement events to journal entries under your accounting rules. Give finance a structured record of how each event affects balances, fees, and amounts owed.

The SaaS model suits a gateway built around the platform’s available APIs and configuration. Your team can develop the checkout and custom provider connections through middleware without modifying the platform’s source code. Confirm the integration scope and operational responsibilities before launch.

The source-code model gives your team scope to customise gateway workflows and provider connections more deeply and deploy the software in your own environment, under the agreed licence. Plan for the engineering, infrastructure, and maintenance responsibilities this involves.

From provider shortlist to a working payment product

Turn the shortlist into a small pilot with clear acceptance criteria. Run representative payments through checkout, reporting, settlement, and refund handling, then compare the results with the terms you agreed. Use the pilot to settle any gaps in integration scope and operational ownership before expanding to more merchants, methods, or providers.

Planning a payment gateway for Nigeria? Discuss your payment gateway project with SDK.finance to map out provider integrations, merchant workflows, and the right deployment model.