How to choose a payment API for your Nigerian business

Choose a payment API by testing whether your team can collect, verify, reconcile and recover payments under real operating conditions. Compare the total cost, settlement terms, regulatory responsibilities and support process. Then run a scoped pilot with written acceptance criteria before committing your main payment flow.

For a Nigerian business, the decision belongs to finance and operations as much as engineering. A quick integration can still leave staff matching transfers manually or investigating orders that never moved out of “pending”.

This guide gives founders, COOs, finance leads and product teams a practical way to compare providers.

1. Define the payment flow you actually need

Start with a one-page brief. Record your currency, typical transaction amounts, expected monthly volume, peak periods and required payment methods. Separate customer collections from transfers to vendors: they are different workflows with different failure cases.

Describe when your business should release goods, credit a balance or activate a subscription. If customers pay by bank transfer, ask whether accounts are temporary or persistent, how references are assigned, and what happens with underpayments, overpayments or transfers after expiry.

Also identify who handles exceptions. A product that accepts payments successfully but gives finance no usable transaction record may move work from software into spreadsheets.

2. Compare payment confirmation, settlement and payouts separately

These terms answer different questions:

• Payment confirmation: Has the customer's transaction reached the provider's documented successful state?
• Settlement: Has the corresponding money reached your nominated bank account under the agreed settlement process?
• Vendor payout: Has an outgoing payment to a supplier or seller completed?

Treat confirmation and settlement as separate stages; each provider's timing and terms must be checked separately.

Ask for cut-off times, weekend and public-holiday treatment, reserves or holds, failed-settlement handling and the reports used to reconcile bank credits. For outgoing payments, ask how an accepted request progresses through pending, successful, failed or reversed outcomes. Never build cash-flow planning around the word “instant” without a precise definition.

3. Calculate costs beyond the headline fee

Request a written quote using your expected transaction mix. Check percentage fees, fixed charges, caps, applicable taxes, account-generation charges, outgoing-transfer fees, refund or dispute charges, minimum commitments and support costs. Ask which charges apply to failed or reversed transactions.

Then estimate the work your own team will do:

• Integration, testing and future API changes
• Manual reconciliation and customer-support investigations
• Maintaining recovery jobs and exception queues
• Migration, reporting exports and eventual provider exit

A useful comparison is the expected monthly provider bill plus internal operating costs. Treat settlement delays as a separate working-capital consideration. Run low-, expected- and peak-volume scenarios so a cheap introductory arrangement does not hide an expensive steady state.

4. Make reconciliation and recovery purchase criteria

Ask a provider to trace one payment from your order reference through confirmation, fees, settlement and any later refund. Your finance lead should be able to follow the same trail without asking an engineer to search production logs.

Look for stable merchant references, authenticated status lookup, downloadable records, clear timestamps and identifiable settlement batches. Check how missing records and amount mismatches are investigated.

Engineering should demonstrate how a missing or repeated webhook is handled. A webhook is a server-to-server event notification; it can trigger processing, but your system still needs to authenticate it and apply the correct business action once. Treat a successful API request and a successful transaction as separate states, prevent duplicate fulfilment, and follow your chosen provider's actual status definitions and authentication rules.

For the implementation details, see our guide to handling duplicate payment callbacks and missing-payment-callback recovery checklist.

5. Check reliability, support and integration effort

Ask what an availability commitment measures. Does it cover the API endpoint, payment processing, webhook delivery or the entire customer journey? Request the measurement window, exclusions, incident communication process and escalation contacts.

Evaluate support with a concrete scenario: “A customer was debited, our order is pending, and the status lookup is unavailable. What evidence do we provide, who owns the case, and when will we hear back?”

Your engineers should review documentation, sandbox limitations, authentication, rate limits, idempotency, webhook retries and API-version changes. Ask which behaviours the sandbox cannot reproduce. A successful demonstration or mock test is useful evidence of implementation logic, but does not establish production availability or bank coverage.

6. Verify onboarding, regulatory roles and data handling

Request the provider's legal entity, the parties involved in moving or holding funds, the applicable licence or regulated-partner arrangement, and evidence supporting that description. Compare relevant entities and categories with the Central Bank of Nigeria's payment service provider list. A brand name alone does not explain the full arrangement.

Ask for the onboarding checklist, restricted business categories, account limits and conditions for production activation before estimating your launch date.

For personal data, review what is collected, why it is needed, who receives it, retention, access controls and incident responsibilities. Use the Nigeria Data Protection Act resources published by the NDPC as a starting point, and have your compliance adviser assess the arrangement. This is a procurement checklist, not legal advice.

7. Use a scorecard, then test the shortlist

The following weights are an illustrative starting point. Adjust them to your business; they are not an industry benchmark.

Score each area from zero to five. Using each weight as percentage points (20 for 20%), calculate weight multiplied by score divided by five, then sum the results for a total out of 100. Record missing evidence rather than awarding points for a sales promise. Treat mandatory legal, security and business requirements as pass/fail gates: a high total cannot compensate for failing one.

Agree pilot acceptance criteria before testing:

1. An expected payment matches the correct order, currency and amount.
2. A duplicate notification produces only one credit and fulfilment.
3. A missing notification can be investigated through authenticated lookup.
4. A timeout remains unresolved until verified, without triggering a second payment automatically.
5. Wrong amounts, late payments and unknown references reach an owned review queue.
6. Finance can reconcile the sample from gross collections through fees to bank credits.
7. Any required vendor payout remains pending until its final outcome is verified.

Assign an owner, evidence and pass/fail result to every test. Include a rollback plan before expanding production traffic.

Frequently asked questions

What is the best payment API for a Nigerian business?

The best fit depends on your payment methods, transaction mix, cash-flow needs and operating capacity. Shortlist against mandatory requirements, compare written terms and test the actual workflow.

Should we choose the lowest transaction fee?

Only after comparing the full provider bill, settlement terms and internal work. A lower fee may be outweighed by manual investigation, reconciliation or migration costs.

Can we evaluate Velvpay with this checklist?

Yes. Request a scoped Velvpay API evaluation with your collection flow, expected volume, settlement needs and integration environment. Ask for current production capabilities, pricing, onboarding requirements and service terms, then agree what evidence a pilot must produce.

Further reading and sources

• Paystack: payment collection and payout timing — a provider-specific example of why confirmation and settlement should be evaluated separately.
• Paystack: verify payments — provider-specific status and server-side verification guidance.

Prepared with AI assistance. The scorecard and pilot tests are illustrative evaluation tools, not results from a live provider comparison.