Bank Account Verification for Marketplace Payouts in Nigeria: A Beneficiary Safety Guide

Bank account verification for marketplace payouts in Nigeria helps answer a critical question before money leaves your platform: are you paying the intended seller? A successful account lookup alone cannot answer that. Your product also needs to connect the destination to the verified business, control account changes and preserve the evidence behind each payout decision.

For marketplaces paying merchants, service providers or logistics partners, beneficiary management deserves its own workflow. This guide explains how to build that workflow around Nigerian bank payouts, with clear boundaries between account validation, business verification and payment execution.

Why a valid account can still be the wrong destination

A bank account can exist and accept transfers while still being unsuitable for a particular seller’s payouts.

Common situations include:

• A seller enters a director’s personal account instead of the approved business account.
• A staff member replaces the destination without the business owner’s approval.
• An attacker takes over a seller profile and adds an account they control.
• A saved beneficiary belongs to the correct business but is no longer its authorised settlement destination.

These are not all account-format problems. Some are identity, authority or account-security problems.

Treat beneficiary verification as a decision supported by several checks, rather than a single green tick returned by a lookup service.

Bank account verification for marketplace payouts in Nigeria: the core workflow

Start by separating three questions that are often bundled together.

1. Is the destination technically valid?

Validate the account number as a string, preserving leading zeroes. Nigerian NUBAN account numbers are generally ten digits, but a length check is only input validation—not proof that the account exists.

Require users to select the bank from a maintained institution list. Do not infer the bank from the account number alone.

Where supported by your payment provider or banking partner, use account-name enquiry to resolve the selected bank and account number. Confirm available endpoints, supported institutions and response semantics in the current integration documentation.

2. Is the destination appropriate for this seller?

Compare the resolved account name with the seller’s verified identity and your permitted payout-account policy.

For a registered business, that might mean an account held in the business’s name. For other seller types, your requirements may differ. Define those requirements with your compliance team and banking partners rather than applying one rule to every seller.

Name enquiry provides a useful signal. It does not establish beneficial ownership, signing authority or the legitimacy of every transaction.

3. Has the destination been authorised?

A suitable account still needs approval from an authorised user.

Require appropriate authentication when adding or replacing a beneficiary. For higher-risk changes, consider independent approval or additional review. The strongest control is not another spelling comparison; it is preventing an unauthorised person from changing where money goes.

Model beneficiaries separately from seller profiles

Avoid storing one editable bank-account field directly on the seller record. That design makes it difficult to reconstruct which account was approved when a payment was created.

Instead, create a beneficiary record with its own lifecycle. Useful fields include:

• An internal beneficiary ID and associated seller ID.
• Bank identifier and securely stored account number.
• Resolved account name and verification timestamp.
• Verification outcome and review reason.
• Creator, approver and approval timestamp.
• Version number and current status.

Possible internal states include draft, verification_pending, review_required, approved, suspended and retired. These are application design examples, not Paddle API status names.

Keep account details out of routine logs. Restrict access to full values and display masked details wherever possible. Apply a documented retention policy to verification evidence rather than keeping it indefinitely.

Use name matching to route decisions, not manufacture certainty

Account-name responses may contain abbreviations, punctuation differences or shortened business names. An exact string comparison can create unnecessary review work.

Normalisation can help by standardising case, whitespace and punctuation. However, aggressive transformations can erase meaningful differences. Removing every business suffix or accepting any shared word can approve unrelated account holders.

A practical decision structure is:

• Clear alignment: proceed to the required authorisation step.
• Plausible variation: request review with the relevant identity evidence.
• Material mismatch: block approval until the destination or supporting evidence changes.
• Unavailable lookup: leave verification pending rather than treating the account as approved.

Make exceptions explicit. If your policy permits a particular alternative account arrangement, record the basis, reviewer and any restrictions. Do not quietly convert a mismatch into a permanent pass.

Avoid revealing the full resolved account name to unauthenticated visitors. Account lookup should support a legitimate onboarding or payout task, not become a public identity-discovery tool.

Treat account replacement as a security-sensitive event

Changing an approved destination is often riskier than adding the first one because a seller may already have funds waiting for settlement.

Require fresh authentication for the change. OTP can be one component, but an OTP sent to a newly changed contact channel should not automatically establish trust. Consider recent password resets, device changes and contact-detail updates alongside the beneficiary request.

Notify the seller through an established channel when a destination is added or replaced. Show masked account details and explain how to report an unauthorised change.

Depending on risk, you may introduce a review period or require another authorised business user to approve the request. Explain any delay before the seller submits the change.

Most importantly, create a new beneficiary version. Do not overwrite the historical destination attached to completed payments.

Bind each payout to an approved beneficiary version

Verification should remain meaningful at the moment of payment execution.

When your system prepares a payout, bind it to a specific beneficiary ID and version. Store the approved destination snapshot securely, along with the approval reference. Immediately before submission, check that the version remains eligible for use.

This prevents a race condition in which a payout is approved for one destination but a background process substitutes a newly edited account.

Define what happens to queued payments when an account changes:

• Payments not yet approved can require the new destination review.
• Approved but unsubmitted payments can be held for explicit reapproval.
• Submitted payments should retain their original destination and transaction history.

Do not silently redirect an existing payment. If the seller suspends an account because of suspected compromise, hold affected unsubmitted payouts and follow your incident procedure.

Practical launch checklist

Before enabling seller-managed payout destinations, test the complete workflow:

1. Define eligibility: document which account-holder types each seller category may use.
2. Confirm integration capabilities: verify institution identifiers, lookup availability and payout requirements with your provider.
3. Separate permissions: distinguish adding a destination, reviewing it and releasing a payout.
4. Test uncertain outcomes: cover lookup timeouts, incomplete names and unsupported destinations without defaulting to approval.
5. Exercise account-change controls: test compromised sessions, recent contact changes and unauthorised staff actions.
6. Test concurrent updates: confirm that editing a beneficiary cannot alter an already approved payout.
7. Prepare support tools: show reviewers masked details, decision history and clear reason codes.
8. Monitor exceptions: track review outcomes, verification failures and beneficiary-related payout failures.

A lookup failure is not necessarily evidence of fraud. Give sellers a safe recovery path and distinguish temporary service problems from policy rejections.

Your policies should reflect applicable requirements and partner-bank expectations. Check the latest CBN circulars where relevant and obtain qualified guidance; this workflow is product guidance, not legal advice.

Build it with Paddle

Paddle provides banking-as-a-service infrastructure for African digital businesses, including instant NIP payouts to 120+ Nigerian banks, KYB/AML verification, OTP and ledgers. These capabilities can support the payment, identity and authentication layers around your beneficiary workflow.

Keep your marketplace’s destination eligibility, approval rules and beneficiary versioning explicit. Before implementation, confirm account-enquiry availability and the exact verification and payout interfaces with Paddle rather than assuming a particular lookup endpoint exists.

Paddle is a platform by Pickpadi Global Ltd, not a bank. Banking services are provided by CBN-licensed partner banks.

Ready to build controlled seller payouts? Create a free account and read the API docs to plan your integration.