How to Build a Payment App in Nigeria

What kind of payment app are you building?

A payment app in Nigeria is any app whose main job is to move money between parties. The main job determines your users, rails and risks, so choose one before scoping.

Decision framework. Answer in writing: what is the one transaction the user must complete on day one; who is on the other side of that transaction; where does the money sit between initiation and completion, and for how long; and who takes the loss when it fails. The answers decide the rail, the partner and half the architecture.

Regulatory route: licensed partner or your own licence

The difference between building on a licensed partner and holding your own licence is who is legally responsible for holding and moving customer funds. As of 2026, the Central Bank of Nigeria (CBN) licenses payment service providers in categories covering switching and processing, payment solution services, mobile money and super-agent activity; confirm the current framework and categories with the CBN or a qualified adviser before deciding.

• Licensed partner rails. Banks, microfinance banks and licensed PSPs expose APIs for virtual accounts, transfers, bill payments, collections and identity checks. You build the app and the ledger of user balances; the partner holds the funds and provides the regulated infrastructure. This is the normal route for an MVP and for most early-stage products.
• Own licence. Required when your model needs you to hold customer funds directly, when partner economics no longer work at your volume, or when you offer regulated services yourself. It brings capital requirements, compliance staff, audits and reporting.

Practical consequence: on the partner route, your app's balance is a view of records at the partner plus your own ledger of who owns what. Keep the two in sync with reconciliation, and never show a balance you cannot trace to a partner record.

The four payment flows you must design first

Every payment app, whatever its type, is built from four flows. Designing their states before the interface is the single most valuable planning exercise.

Two rules follow. First, every request to a partner carries a unique reference that is stored before the call is made, so retries never create duplicate transactions (idempotency). Second, "pending" is a real state shown honestly to the user with an expected resolution time, never rounded to "failed" or "successful".

Core features of a payment app

Features vary by type, but the shared foundation is consistent. A consumer or merchant payment app in Nigeria typically needs the following at launch.

• Onboarding with tiered verification. Phone number, BVN or NIN checks through partner services, and limits that grow with verification level. Design the path for a customer whose records do not match.
• Funding. A dedicated virtual account (the most trusted method for Nigerian users), card funding and USSD where the partner supports it.
• Transfers with name enquiry. Showing the recipient's account name before sending is the feature Nigerian users trust most.
• Bills, airtime and data with a clear status per item and a receipt.
• Receipts and history that can be shared on WhatsApp, since users prove payments this way.
• Merchant tools where relevant: QR code, payment links, settlement summary, and a simple sales view for the shop owner.
• Limits and controls. Daily and per-transaction limits enforced on the server; transaction PIN; the ability to freeze the account from the app.
• Support channel inside the app, with the transaction reference attached automatically.
• Operations console (web). Transaction search by reference, manual reversal and refund workflows with approvals, user verification queue, limit overrides with audit trail, reconciliation exceptions and reports.

The operations console is where your team will spend its day. It should be scoped as a full product, not a leftover.

Failures, reversals, disputes and reconciliation

Handling failure well is the core competence of a payment business. The difference between a trusted payment app and an untrusted one is what happens in the hour after a transfer goes wrong.

1. Detect. Monitor pending transactions; anything beyond the partner's stated window is raised automatically.
2. Query. Use the partner's transaction status endpoint before deciding. Never assume from a timeout.
3. Resolve. Confirm success, or reverse the debit on your ledger and inform the user, with a reference.
4. Communicate. In-app status, push notification and, where useful, SMS. Silence generates support tickets and social media complaints.
5. Reconcile. Match partner statements to your ledger daily. Investigate every exception, including fees.
6. Handle disputes. Chargebacks on cards and claims of "I paid but the merchant did not receive" need a defined workflow with evidence, deadlines and a person who decides.

Build all of this into the operations console with approvals and an audit trail. Manual reversals by a single staff member with database access are a fraud risk and an audit failure.

Security and fraud controls for payment apps

Payment apps attract fraud from day one. The baseline controls are:

• server-side enforcement of limits, validations and authorisation;
• device binding, transaction PIN and biometrics, with OTP for high-risk actions such as new beneficiaries or device changes;
• velocity rules (many transfers in a short window, rapid fund-and-withdraw patterns), new-account restrictions and a case queue for review;
• secure storage of secrets, no sensitive data cached on the device, certificate pinning and tamper detection;
• webhook signature verification, so an attacker cannot fake a "payment received" event;
• role-based access in the console with two-person approval for reversals and limit overrides;
• independent penetration testing before launch and after major changes;
• data protection controls for personal and transaction data, in line with the Nigeria Data Protection Act 2023; confirm current requirements with the Nigeria Data Protection Commission.

Partners will ask about most of these before granting production access. Prepare the answers as part of the build.

How to build a payment app: step by step

The first step is a one-page definition of the day-one transaction, the user on each side, and the partner rail you will use.

1. Define the transaction and the user. One type, one segment, one city or community to start.
2. Choose the regulatory route and partner. Compare two or three licensed partners on API coverage, settlement timing, fees, sandbox quality and onboarding requirements. Get requirements in writing.
3. Design the money model. The four flows, their states, the internal ledger structure (double-entry, immutable entries), fees and who bears them.
4. Design the operations console. Reversals, refunds, verification, limits, reconciliation, reports.
5. Design the app. Onboarding, funding, transfer, bills or merchant flows, receipts, support. Test the flows with target users on their own phones.
6. Build the backend and ledger. Idempotent partner integrations, webhook handling, status polling, notifications, roles.
7. Build the app. Cross-platform (Flutter or React Native) is common for payment apps; native modules handle biometrics and security features.
8. Integrate with the partner sandbox, then production. Test every failure mode: timeouts, duplicates, pending, wrong reference, partial fulfilment.
9. Commission penetration testing and complete the partner's go-live checklist.
10. Run a closed pilot with a few hundred users; reconcile daily by hand until the automated report matches for two consecutive weeks.
11. Launch and publish on Google Play and the Apple App Store under your company's accounts.
12. Operate. Monitoring with alerts on failure rates, fraud rule tuning, partner relationship management, and a maintenance agreement.

What changes for payment apps in Nigeria

Payment behaviour in Nigeria shapes the product in specific ways.

• Bank transfer is the default. Users fund wallets and pay merchants by transfer to a virtual account, often from their bank app. Card is secondary for many segments, and USSD matters for users without data.
• Receipts are social proof. Users forward receipts on WhatsApp to prove payment to landlords, schools and suppliers. A clear, shareable receipt is a core feature.
• Network congestion is predictable. Month-end, salary days and festive periods bring transfer delays across the industry. Design pending states, retries and customer communications for those days.
• Cash and agents remain important. Outside major cities, agents are how many people convert cash to digital balance. An agent mode with float management and receipts can be the product's most used feature.
• Trust is earned through name enquiry, reversals and support. Users judge a payment app by whether a failed transfer is reversed quickly and whether a person answers.
• Fee sensitivity. Users notice transfer fees and stamp duties. Show fees before confirmation; unexplained deductions generate complaints and churn.
• Exchange rate. USD-priced services (hosting, SMS gateways, some fraud tools) drift with the naira; budget accordingly.

Example (hypothetical): an estate levy and utility payment app in Abuja

Example (hypothetical): A facility management company that manages twelve residential estates in Abuja collects service charges, security levies, water and waste fees by bank transfer, then chases residents on WhatsApp and reconciles in spreadsheets. It plans a payment app so residents can see what they owe and pay in the app, and so estate managers can see collections in real time. Its day-one transaction is a resident paying a specific invoice. The company chooses the partner-rail route through a licensed payment provider: each resident gets a dedicated virtual account so transfers are matched automatically, cards are supported, and payouts to each estate's account run daily by split settlement. Electricity token purchase is added through a bill aggregator because residents asked for it. The MVP: resident app with invoices, payment by transfer or card, receipts, payment history and a support chat; an estate manager web console with collections, defaulters, reconciliation exceptions and exports; automated reminders before due dates. Recurring card payments, visitor management and a marketplace of estate services are deferred. Failure handling covers unmatched transfers (resident pays from a different bank without the reference) with a manual match queue in the console. Indicative planning budget for this example: ₦6,000,000–₦12,000,000 for the build, plus provider fees per transaction, hosting, SMS and a maintenance retainer. The success measure is the share of levies paid in-app without a manual follow-up.

How much does it cost to build a payment app in Nigeria?

Payment apps range from medium to complex depending on how many flows, partners and user types they support. The following are indicative 2026 ranges; actual quotes vary with scope, vendor and exchange rate. Compare two or three written quotations on identical scope.

Recurring costs: partner and gateway fees per transaction (often a percentage plus a fixed amount, with caps that vary by provider), SMS and OTP costs, hosting (₦150,000–₦800,000+ per year for a modest deployment, rising with volume), penetration testing, app store accounts (Apple Developer Program a yearly fee, historically US$99; Google Play registration one-time, historically US$25; verify current fees), maintenance at roughly 15–25% of build cost per year, and support staff. If you pursue your own licence, add capital, compliance and audit costs that dwarf the software budget.

Mistakes to avoid

• Building the app before the money model. Screens are cheap to change; a ledger that cannot explain a balance is not.
• Treating timeouts as failures. A timed-out transfer may have succeeded. Query status before reversing, or you will pay twice.
• Trusting webhooks without verification. Unsigned or unverified "payment received" events are an open door to fraud.
• No idempotency. Retried requests without unique references create duplicate transfers and unhappy users.
• Skipping reconciliation until "later". Small mismatches compound; by month three the books cannot be trusted.
• A weak operations console. If reversals need a developer, every incident becomes an engineering ticket and a compliance problem.
• Hidden fees. Show the fee before confirmation. Surprises drive users back to their bank app.
• Ignoring the partner's go-live checklist. It is a project in itself. Start it in month one, not the week before launch.

Conclusion

A payment app in Nigeria is defined by how it behaves when transactions go wrong, not by how the successful ones look. Choose one payment job, settle the regulatory route, design the four flows and their failure states, and build an operations console that lets people fix problems with approvals and an audit trail. Reconcile daily from the first pilot transaction, show fees and pending states honestly, and treat the partner's go-live checklist as part of the project plan. The screens are the easy part. If you are planning a payment product and want a technical partner to design the money model, partner integrations and operations console alongside your compliance adviser, Linestech builds payment and financial applications for Nigerian businesses and can help scope a lean first release.

Frequently asked questions

Do I need a CBN licence to build a payment app in Nigeria?

Not necessarily. Many payment apps launch on the rails of licensed banks and payment service providers, which hold the funds and carry the regulated activity. A licence of your own becomes relevant when you need to hold customer funds directly or offer regulated services yourself. Confirm current requirements with the CBN or a qualified adviser.

How do virtual accounts work in a payment app?

A licensed partner issues a unique bank account number per user or per invoice. When money is transferred to it, the partner notifies your backend by webhook and your ledger credits the right user automatically. Virtual accounts are widely trusted in Nigeria because users pay from their own bank apps.

What happens when a transfer is debited but the recipient is not credited?

Your backend should query the partner's transaction status, and either confirm the credit or reverse the debit on your ledger and notify the user. The interbank system reverses failed transactions within defined windows; your app must show the pending state honestly and give the user a reference to track it.

Can a payment app work with USSD or on basic phones?

The app itself needs a smartphone, but many providers offer USSD-based funding or payment options that you can integrate, and agent modes extend the product to customers without smartphones. Whether USSD is worth adding depends on your target users.

How long does it take to build a payment app in Nigeria?

A partner-rail MVP typically takes four to eight months from a fixed scope to public launch, including partner onboarding, integration testing, penetration testing and a closed pilot. Partner approval and go-live checklists often take longer than development.

Should the payment app hold user balances at all?

Only if your model requires it and your partner arrangement supports it. Many products avoid stored balances entirely: the user pays a specific invoice or merchant, and the money settles directly to the recipient. Holding balances brings additional obligations; take advice before designing a wallet.

Sources and further reading

Figures, platform rules and regulations change. These are the primary references behind this article and the places to check before you act on it.

• Nigeria Data Protection Commission (NDPC)
• Central Bank of Nigeria (CBN)
• Apple Developer Program
• Node.js documentation
• OWASP Top 10
• TechCabal — African technology news
• Techpoint Africa