How to Add Payments to a Mobile App

Which payment methods should a Nigerian app offer?

A Nigerian app should offer at least three ways to pay: debit card, bank transfer to a virtual account, and USSD. Cards are convenient but fail often on online transactions; transfer is the most trusted method for many customers and works from any bank app; USSD covers customers on basic phones or without data at the moment of payment. Gateways bundle all three behind one integration, and most also route mobile-money wallets.

Offer transfer and card as equals in the interface rather than burying transfer under "other options". Many customers will choose it first.

Gateway, app store in-app purchase, or both?

The difference between a payment gateway and app store in-app purchase (IAP) is what you are selling. Apple's App Store and Google Play require that digital content and features consumed inside the app be sold through their IAP systems, which take a commission. Physical goods, real-world services, and payments for things delivered outside the app (a meal, a ride, a laundry pickup, school fees, a hotel room) are generally exempt and can use a Nigerian gateway directly.

Store policies and exceptions have shifted in recent years. Read the current App Store Review Guidelines and Google Play payments policy for your category before deciding, because an app rejected at review for using the wrong route loses weeks. If IAP applies, budget for the Apple Developer Program yearly fee (US$99 historically) and Google Play's one-time registration fee (US$25 historically); verify current fees.

Three ways to put the checkout in your app

Once you have chosen a gateway, the payment screen itself can be integrated in one of three ways.

For most apps, the gateway SDK or hosted checkout is right, with the virtual account displayed inside the same flow. Never build your own card entry form: you would take on PCI DSS obligations that gateways exist to carry for you, and customers trust the gateway's screens more than yours.

The backend does the real work: initiate, verify, webhook, update

The single rule of payment integration is that the app never decides an order is paid. The sequence that keeps money and orders in agreement:

1. Initiate on the backend. The app sends "pay for order 4471". Your backend calculates the amount from its own records (never trusting an amount sent by the app), creates a transaction with the gateway using a unique reference, and returns the reference and checkout details to the app.
2. Collect payment in the app. The SDK or hosted page takes the customer through card, transfer or USSD.
3. Receive the webhook. The gateway sends an event to your backend when the payment succeeds or fails. Your backend verifies the webhook signature, checks the amount and currency against the order, and only then marks the order paid.
4. Verify on demand. When the app returns from checkout, it asks your backend for the order status; if the webhook has not arrived yet, the backend can query the gateway's verification endpoint by reference.
5. Make it idempotent. Webhooks can arrive twice, and users can retry. Every update must be safe to process more than once, keyed by the transaction reference.
6. Update and notify. Order status changes, receipt is generated, customer and operations are notified.

Webhook endpoints must be reachable from the internet and must respond quickly; if your backend is offline when a webhook arrives, most gateways retry for a period, but your reconciliation job should still catch anything missed.

Designing for Nigerian payment realities

Nigerian payments succeed in ways and fail in ways that international tutorials do not cover. Design for these from the start:

• Transfers arrive late or without a reference. A customer may transfer from a bank app minutes after the app screen timed out. The order must stay "awaiting payment" with a clear message, and the webhook must match the payment to the order when it lands.
• Cards fail for reasons the customer cannot fix on the spot. Daily limits, international-transaction blocks, and bank downtime all show up as declines. Show the failure plainly and offer transfer or USSD immediately.
• Network drops mid-payment. The customer's data may cut between authorising and returning to the app. The app should recover the pending order on next launch and ask the backend for the real status.
• Duplicate payments. A customer who thinks the first transfer failed may pay again. Detect duplicates by matching amount and customer, flag for refund, and never silently keep the money.
• Cash and POS still exist. For physical deliveries, a pay-on-delivery option with rider collection tracking may lift completion rates more than any card optimisation.
• Bank downtime and gateway incidents. Have a status message ready and a way for operations staff to mark an order paid manually with an audit trail when a customer shows proof of transfer.
• Receipts and trust. Nigerian customers screenshot everything. Generate a receipt with reference, amount, date and your registered business name, and send it in the app and by email or WhatsApp.
• Currency and pricing. Price in naira. If any component of your cost is in US dollars (hosting, tools), the gateway fees you pay per transaction are in naira, but plan margins with exchange-rate movement in mind.

Refunds, disputes and reconciliation

Refunds should be initiated from your backend or admin dashboard through the gateway's refund API, recorded against the original transaction, and reflected in the order state. Partial refunds are common for orders with missing items; build for them. Disputes and chargebacks come through the gateway, usually with a deadline to respond with evidence. Keep delivery confirmations, timestamps and customer communications attached to the order so operations staff can respond in minutes. Reconciliation is the daily or weekly job that compares your backend's list of paid orders with the gateway's settlement reports and your bank statement. Differences reveal missed webhooks, duplicate payments and fee surprises. Automate the comparison early; doing it in a spreadsheet works for the first hundred orders and fails silently after that.

How to add payments to a mobile app: step by step

1. Map every payment scenario in writing. Successful card, successful transfer, late transfer, failed card, USSD timeout, network drop, duplicate payment, refund, partial refund, dispute.
2. Choose the gateway and open a business account. You will need CAC registration, a corporate bank account and identity documents; approval can take days, so start early. Compare fees, settlement times and supported methods on the providers' current documentation.
3. Decide the store route. Confirm whether any part of your app must use in-app purchase.
4. Build the backend flow. Order amounts from your records, transaction creation, webhook endpoint with signature verification, verification-by-reference, idempotent updates, refund calls, admin manual-confirm with audit trail.
5. Integrate the checkout in the app. SDK or hosted checkout, with the virtual account shown in the same flow, clear pending states, and recovery of pending orders on launch.
6. Test every scenario in the gateway sandbox. Use the test cards and simulated transfers the gateway provides; then run a small live test with real money and real bank apps.
7. Set up receipts, notifications and reconciliation. Receipts to customers, alerts to operations, a daily reconciliation report.
8. Launch to a small group. Watch the first hundred transactions closely; the edge cases you did not imagine will appear here.
9. Review monthly. Success rates by method, failure reasons, refund volume, dispute outcomes and fees.

Example (hypothetical): a Port Harcourt laundry pickup app adds payments

Example (hypothetical): a laundry and dry-cleaning business in Port Harcourt has an app where customers schedule pickups, but payment happens by transfer to a personal account with screenshots sent on WhatsApp, and matching payments to orders takes a staff member two hours a day. The team integrates a Nigerian gateway through its cross-platform SDK. Because laundry is a physical service, the app store IAP rules do not apply. At checkout the app offers card, transfer to a virtual account tied to that order, USSD, and pay-on-collection for customers who prefer it. Amounts come from the backend's price list after the items are weighed and confirmed, so the customer pays the final figure, not an estimate. The backend creates each transaction, verifies webhooks, marks orders paid, and sends a receipt with the business's registered name in the app and by WhatsApp. Late transfers are matched automatically to the order's virtual account; duplicates are flagged for refund within the day. A daily reconciliation report compares paid orders with gateway settlements. The staff member who used to match screenshots now handles exceptions only. The figures are illustrative and not client results.

How much does it cost to add payments to a mobile app?

Indicative 2026 ranges are shown below; actual quotes vary with scope, vendor and exchange rate. Integration cost depends mostly on the number of scenarios you handle properly and the state of your existing order logic, not on the gateway chosen.

Recurring costs, separate from the build: gateway transaction fees on every payment, charged in naira per the provider's current schedule; app store commission where IAP applies; hosting for the webhook endpoint (usually part of your existing backend); and maintenance of SDK versions, typically part of your app's 15–25 percent per year maintenance budget. When comparing quotations, give each vendor the same written scenario list and ask which scenarios are included, whether webhook verification and idempotency are built, and whether reconciliation is in scope. A quote that covers only "Paystack integration" may mean a checkout button with no backend verification.

Mistakes to avoid

• Marking orders paid from the app. The SDK's success callback is not proof; the webhook and backend verification are.
• Trusting amounts sent by the app. Calculate on the server; a modified app can send ₦100 for a ₦10,000 order.
• Ignoring the webhook signature. Unverified webhooks let anyone mark orders paid.
• No pending state for transfers. Customers who transferred after the screen closed will be told they did not pay.
• Building your own card form. You inherit PCI obligations and lose customer trust.
• Using the wrong store route. Selling digital goods through a gateway inside the app risks rejection.
• Skipping reconciliation. Missed webhooks and duplicates surface months later as accounting problems.
• One payment method. Card-only or transfer-only apps lose sales to the failure modes of that method.

Conclusion

Adding payments to a mobile app in Nigeria is a backend project with a checkout screen attached. Offer card, transfer and USSD as equals, integrate a licensed gateway through its SDK or hosted checkout, and make your server the only authority on whether an order is paid: it creates the transaction, verifies the webhook, handles late transfers and duplicates, and reconciles against settlements. Use app store in-app purchase only where the rules require it. Map every scenario before you build, test them all in the sandbox, and watch the first hundred live transactions closely. If your app needs to take money reliably from Nigerian customers, and you want the backend verification, reconciliation and failure handling done properly the first time, Linestech integrates payment gateways into mobile apps and can scope the work against your order flow.

Frequently asked questions

Which payment gateway is best for a Nigerian mobile app?

There is no single best. Paystack, Flutterwave, Monnify and others all support cards, transfers and USSD with mobile SDKs and webhooks. Compare current fees, settlement timing, supported methods, SDK quality for your framework, and support responsiveness on their own documentation, and choose the one whose onboarding you can complete quickly. Build the backend so switching later is possible.

Can customers pay by bank transfer inside the app?

Yes. Your backend requests a virtual account number for the order from the gateway, the app displays it, and the customer transfers from their bank app. The gateway sends a webhook when the transfer lands, and your backend marks the order paid. Keep the order in a pending state until that confirmation arrives.

Do I need Apple Pay or Google Pay in Nigeria?

Not usually. Availability and adoption in Nigeria are limited as of 2026, and local methods cover the market. Focus on card, transfer, USSD and wallets through your gateway, and revisit if your customers ask.

How do I handle a customer who paid twice?

Detect duplicates on the backend by matching amount, customer and timing, flag the second payment, notify the customer, and refund through the gateway's refund API with a record against the order. Never keep a duplicate silently; it becomes a dispute and a reputation problem.

Is it safe to save customers' cards in my app?

Card details themselves are never stored by you. After a successful payment, the gateway returns a token, which your backend stores and can use for later charges with the customer's consent. Not all cards support reuse, so keep alternatives available. Secure the tokens as you would any sensitive data.

What do I need before a gateway will approve my business?

Typically CAC registration, a corporate bank account, director identification and a description of what you sell. Requirements vary by provider and business type and can change; check the current onboarding page of your chosen gateway and allow several days for approval.

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.

• Corporate Affairs Commission (CAC)
• Paystack developer documentation
• Flutterwave developer documentation
• Apple Developer Program
• Flutter documentation
• Node.js documentation
• Baymard Institute e-commerce UX research