How Merchant Onboarding Protects Payments and Payouts

Merchant onboarding has far more moving parts than it is often given credit for. Done properly, it helps a platform understand who is selling, who controls the account, where payouts are going, and whether the merchant still fits the profile that was originally approved.

This article explains what merchant onboarding covers, who needs it and why, how the entire process works, and what is worth building into the system from the start.

In practice, KYM often combines Know Your Customer (KYC) for the people behind the account and Know Your Business (KYB) for the legal entity. Additionally, it can involve payment-specific review of the store, payout path, and loss exposure. 

Some of the most common data points to collect can be summed up as follows:

Merchant onboarding is needed by any business that gives outside sellers the ability to take payments or receive payouts. The depth of checks should depend on what the seller is allowed to do.

The main groups are:

• Acquirers. These are banks or payment companies that connect merchants to card networks so they can accept card payments.

• Payment service providers (PSPs). A PSP helps merchants take online payments through cards, wallets, bank transfers, or local payment methods.

• Payment facilitators (PayFacs). A PayFac onboards sub-merchants under its own payment setup, which makes speed attractive but also raises risk.

• Marketplaces and platforms. Marketplaces connect buyers and sellers, while platforms may add payments to booking, delivery, creator, healthcare, education, or B2B products.

• Vertical SaaS companies with embedded payments. Software companies that add payments inside their product become part of the seller’s money movement.

• Businesses that support regulated or high-risk categories. Sellers dealing with alcohol or prescription products, for example, may need license checks and category controls in addition to identity and business verification.

It must be mentioned that, from a legal point of view, KYM is not universally compulsory. The specific legal duty will depend on who the company is, where it operates, and what payment role it has. 

For instance, covered US financial institutions have customer due diligence duties that include customer identification, beneficial ownership checks, customer risk profiles, and ongoing monitoring.

FinCEN’s rule also refers to a 25% beneficial ownership threshold and one control person for legal-entity customers. FATF standards tend to push countries toward adequate, accurate, and up-to-date beneficial ownership information for companies.

More specifically, some of the most tangible benefits are:

• Reduced direct payout losses. Verifying the business, the authorized person, and the payout destination before funds are released makes it harder for fake sellers to collect money and disappear.

• Lowered cost of bad merchants. Weak sellers create more disputes, refunds, manual reviews, support cases, and payout investigations; screening them earlier protects your margin.

• Easier acquiring and banking relationships. A platform with poor seller controls can face stricter oversight from its acquirer or sponsor bank, while a good onboarding record gives those partners more confidence.

• Enabled risk-based pricing and permissions. Stronger evidence lets the platform grant faster payouts or sensitive-category access to reputable merchants, while keeping weaker applicants on slower settlement or lower caps.

• Improved quality of the merchant portfolio. When approval rules remove sellers that are likely to generate losses or regulatory concern, the platform keeps more revenue from good merchants and spends less money supporting bad ones.

The merchant onboarding process should cover the whole seller relationship. That’s why it’s a good practice to run the following three tracks together: business proof, person proof, and payment-risk review.

At this point, the business does not know the merchant’s final risk rating. It only knows what the seller claims to be and which permissions it wants.

The factors that set the first route are:

• what type of business is applying

• where the merchant is established

• what the merchant wants to sell

• which payment rights it is requesting

Country, entity type, category, expected volume, and requested capabilities can then determine which data and checks are needed. Generally, as the seller reaches higher processing or payout thresholds, more proof should be requested.

Then, Know Your Business checks are performed to confirm that the entity exists, is active, and matches the data in the merchant application. This may include registry checks, tax data, business address, trading name, and license review.

For companies, KYB should also map beneficial ownership. A registration record alone is not enough when the risk assessment depends on who owns or controls the merchant. 

Entity screening can also begin as soon as the legal name, trading name, country, and registration data are resolved. Sanctions, adverse media, internal blocklists, and prior merchant-termination records may be relevant, but the exact checks depend on the company’s role and its acquiring or network obligations.

Merchant verification should cover the people whose role affects ownership, authority, or control over funds. Depending on the merchant type, this may include a beneficial owner, a control person, an authorized signer, or a user who can change payout details.

One of the most commonly used methods for identity verification here is document authentication. Specialized software like Regula Document Reader SDK identifies the document type, extracts data, and compares information from the visual zone, MRZ, barcode, or RFID chip when available.

This can reveal expired documents, altered data, replaced portraits, inconsistencies between data sources, or signs that the document image was captured from another screen.

Less commonly, but still applicable in high-risk situations, the platform can perform face verification as well. It is most useful when the business needs stronger proof that the remote applicant is the holder of the document—for example, before giving a sole proprietor payment access, granting payout rights to an authorized signer, or approving a sensitive account change.

This biometric check has two separate parts:

• Liveness detection checks that the camera is seeing a present person rather than a printed photo, injection, screen replay, mask, or manipulated media.

• Face matching compares the live capture with the portrait taken from the ID document or, where available, its RFID chip.

Where the platform or payment company sends funds to the merchant, the payout account should be checked before money is released. The account holder should match the merchant or an accepted related party, and supporting bank evidence may be requested when automatic verification cannot confirm the details.

Keep in mind that account creation and payout permission do not have to be granted at the same moment. A seller may complete setup while payouts remain blocked until business, identity, and bank checks are cleared.

The store, app, or seller page should be compared with the merchant application. A company can be real and still sell something different from what it declared.

The reviewer should be able to state why the selling channel matches the application and why the MCC or category makes sense. Product claims and refund terms are often enough to reveal a mismatch without turning every review into a full content audit.

Underwriting decides how much risk the business is willing to take before the seller begins processing. This becomes very important when dealing with refunds, disputes, delayed delivery, payout timing.

For example, a merchant with a higher-risk category may need lower limits until clean processing history is available.

The decision should ideally be more precise than approve or reject: a merchant can still be approved with limits, paused for missing proof, sent to manual review, or refused with a clear reason.

The case record should keep the evidence used, the checks run, the rule or policy applied, reviewer notes, and the activation terms.

Ongoing monitoring compares the approved risk profile with later behavior through transaction monitoring, website review, payout-change checks, and screening updates.

You should react swiftly when risk changes: useful triggers include a new payout account, a new owner, a new product category, a sanctions hit, or a sharp increase in refunds or chargebacks.

Even a carefully designed merchant verification process can leave expensive gaps that are not particularly obvious. In this section, we have collected four things we find very important to have in the flow, for various reasons.

Account setup carries less exposure than releasing funds or turning on card processing. A marketplace may allow a seller to finish setup while keeping payouts blocked; an acquirer or PSP may hold payment activation until the business and authorized person have been verified, with payout ownership and licensing checked where relevant.

The same gate should return after a bank-account change or suspicious account recovery. For merchants with delayed delivery or high dispute exposure, approval can also carry a reserve or slower settlement until processing history supports better terms.

Fraudulent applicants may change the company name and email yet reuse a verified identity or payout account. Merchant verification software should connect those records and send unusual links to review before another account is approved.

A match is not an automatic rejection. Group companies may share directors, and franchises may use common business details, so the reviewer still needs context.

A current website does not tell the reviewer what was approved six months earlier. The case should retain a dated view of the storefront and declared category, together with the refund or delivery terms used in underwriting.

That record gives later monitoring a reference. When the seller adds a new domain or starts offering materially different products, the team can compare the current business with the approved one and decide whether new evidence, a different MCC, or revised settlement terms are needed.

An alert has little value if nobody knows whether payouts should pause, who must review the case, or what evidence will clear it. Each trigger should carry a written response rule based on severity, with a named owner and a decision deadline.

The platform should track the time from trigger to decision and, where funds remain active, the amount released while the review is open. A sanctions alert and a moderate increase in refunds should not receive the same treatment: the first may require an immediate hold, while the second may call for closer review without interrupting a good merchant unnecessarily.

Seller approval should grant trust in stages. Identity proof belongs before payout authority, business proof before higher volume, category proof before sensitive goods, and lighter review after a clean operating history rather than at the first sign-up screen.

Regula IDV Platform can support this model when a platform needs document checks, biometrics, screening, and case evidence retention in one flow. It combines two solutions (document verification and biometric verification) to cover the full spectrum of identity checks and allows managing all verification workflows, depending on the use case.

Together, Regula’s solutions offer:

• Document authenticity checks, data extraction and cross-validation of MRZ, barcode, and RFID chip data

• The largest document database in the world, with 16,000 ID templates from 254 countries and territories, plus 138+ languages and scripts;

• Face matching and liveness detection that blocks printed images, video replays, injections or masks for seller onboarding, buyer step-up checks, account recovery, and age-restricted sales;

• KYC checks, AML, sanctions screening, centralized user profiles, and identity lifecycle management;

• Audit trail and case management for or dispute resolution or regulatory review of why a merchant was approved/rejected with full visibility into each verification session.

• Hosted cloud or 100% on-premises deployment for teams with strict privacy, data-control, or residency requirements;

• Mobile, web, API, kiosk, and reader-based verification paths for different scenarios.

Want to know more about how Regula can support your business? We're just a message away.