Most merchant onboarding programs fail because they were designed for lower volume than they're now running. Manual processes that worked at 50 applications monthly don't hold at 500.

Fraud controls that caught bad actors in small portfolios create unacceptable approval delays in large ones. What looked like a risk program turns out to be a headcount dependency.

Merchant onboarding verifies a business before allowing it to accept electronic payments. ISOs, payfacs, and SaaS platforms with embedded payments all run versions of it. The differences between programs — in fraud exposure, approval speed, operational cost, and chargeback rates — come down to how the process was designed and whether it was built to scale.

This guide covers how onboarding works across the payments ecosystem, where most programs have structural gaps, and what the operational and risk tradeoffs actually look like.

‍

What merchant onboarding is and why it matters for payment providers

Merchant onboarding is how a payment provider establishes that a business is legitimate, understands the risk it presents, and decides whether — and on what terms — to allow it to process payments.

For ISOs, payfacs, and SaaS platforms with embedded payments, this is not an administrative formality. It is the primary control point against fraud losses, chargeback exposure, and card network compliance violations. A merchant that passes onboarding with inadequate scrutiny can generate losses that far exceed what it contributed in processing revenue. A merchant stuck in a slow onboarding process may abandon the application entirely — a real conversion problem for platforms where payment acceptance is a core product feature.

The tension between speed and risk coverage is the central design challenge in merchant onboarding. Programs that resolve it well use automation to approve clearly low-risk merchants instantly and reserve human review for cases that actually require judgment. Programs that don't resolve it tend to do one of two things: move slowly on everyone, or move quickly on everyone and absorb the fraud losses that follow.

‍

How onboarding works differently across ISOs, payfacs, and SaaS platforms

The mechanics of merchant onboarding vary based on who holds liability and how the processing relationship is structured.

Payment facilitators

Payfacs board merchants under a master merchant account and carry direct acquiring liability for every merchant they onboard. This liability structure creates strong incentives for rigorous underwriting — a single high-risk merchant committing fraud or running up chargebacks generates losses the payfac absorbs directly.

Payfacs typically compete on onboarding speed, with the model able to reduce onboarding from weeks to minutes. The payfac model exists in part because traditional acquiring relationships are slow. The operational challenge is running thorough underwriting fast enough that it doesn't undermine the speed advantage the model is supposed to deliver.

Payfacs that do this well use tiered underwriting: automated decisioning for low-risk merchants, with manual review reserved for edge cases. The result is same-day or near-instant approval for the majority of applicants, with deeper review applied where it actually changes the decision.

ISOs

The ISOs that operate at scale — and the ones that need merchant risk infrastructure — own underwriting liability directly. They are responsible for the merchants they board, absorb exposure when those merchants generate chargebacks or commit fraud, and manage portfolio risk the same way a payfac does.

For these ISOs, onboarding is not a facilitation function. It is a risk function. The decisions made at application — which merchants to approve, on what terms, with what monitoring — determine the health of the portfolio and the exposure the ISO carries. ISOs with strong merchant screening at onboarding protect themselves from losses that accumulate downstream and are difficult to recover once funds have settled.

SaaS platforms with embedded payments

Vertical SaaS companies with embedded payments face a different operational reality than standalone payfacs. Their merchants are typically existing software customers — businesses that already have a relationship with the platform and are activating payments as an additional feature, not shopping for a payment processor.

This changes the cost of onboarding friction in a way that most risk frameworks don't account for. When a merchant abandons a payments application at a payfac, the payfac loses that processing revenue. When a merchant abandons a payments application at a SaaS platform, the platform risks losing the entire software relationship. Payments churn and software churn become correlated. A slow or complicated onboarding experience isn't just a conversion problem — it's a retention problem.

Approval speed carries more weight here than in other contexts. A payfac can accept a 48-hour approval time for edge cases because the merchant came specifically for payment processing and will wait. A SaaS platform serving home services businesses cannot make the same assumption — a contractor who can't get approved in the same session they signed up for software is a churn risk by the next morning.

Most SaaS platforms with embedded payments don't have dedicated risk teams. The payments lead — sometimes a single person — owns onboarding alongside everything else.

The practical requirement is a system that handles routine cases automatically, surfaces exceptions that need attention, and doesn't require deep risk expertise to configure or operate. Generic risk infrastructure built for payfac operations often doesn't fit this context without significant customization.

‍

What gets collected and why it matters

Document collection serves two purposes: verifying the business is legitimate and generating the signals needed to assess risk. Requirements vary by provider and volume, but the categories are consistent across the industry.

Business identity and registration — legal name, DBA, EIN, state registration, articles of incorporation — confirms the business legally exists and operates where it claims to. It is also the easiest step to automate: business registration data is structured, machine-readable, and available in seconds from commercial and government sources.

Beneficial ownership — ownership structure, UBO identification, government-issued IDs for principals — satisfies AML compliance requirements and establishes who actually controls the business. Shell structures and nominee ownership are common fraud patterns; UBO verification is the control against them. This is where synthetic identity fraud most often surfaces — the business registration may be real while the person claiming to own it is not.

Financial and processing history — bank statements, prior processing statements, chargeback and refund history — informs credit risk assessment. A merchant with 18 months of clean processing history at a prior processor is a materially different risk than a new business with no record. Prior processing history is the single strongest predictor of future chargeback rates at onboarding; programs that can access and incorporate it have a structural advantage over those that can't.

Website and product information — URL, product descriptions, pricing, refund policies, terms of service — is where underwriters verify that the merchant's stated business model matches reality. Website review is the most consistently under-resourced step in manual onboarding programs and the one most likely to catch a prohibited business that passed document verification. It also degrades fastest under volume — when analysts are under pressure, website review is what gets skimmed.

‍

Where merchant onboarding programs actually fail

Most failures don't stem from poor theoretical design. They happen because programs were designed for lower volume, or because manual processes don't scale.

Shallow website review allows fraud through. Business registration and identity verification catch some fraud. They miss merchants with prohibited products, bait-and-switch models, or business categories that don't match what they're actually selling. Manual review is slow and inconsistent; automated screening catches what it misses at scale.

Synthetic identity and business impersonation fraud passes document verification. A well-constructed fraudulent application can look clean on paper — 95% of synthetic identities are estimated to pass onboarding undetected. The business registration is real — created specifically for the fraud. The identity documents belong to a real person — just not the applicant.

Fraud models trained on merchant-specific signals detect patterns document verification cannot: disposable phone numbers, email domains that don't belong to the business, IP signals inconsistent with the application address, applicant identities that don't associate with the business.

Analyst capacity becomes the bottleneck. Manual review of every application caps throughput by headcount. Volume spikes — seasonal, after a product launch, after a new sales push — create backlogs that slow approvals across the board, including for low-risk merchants that could have been auto-approved. Scaling headcount is expensive and doesn't solve the underlying design problem.

Onboarding treated as a one-time decision. A merchant that was legitimate at approval can become a risk six months later. Without transaction monitoring running continuously after onboarding, an onboarding program is making a permanent decision based on a point-in-time snapshot.

‍

When risk concentrates in the merchant lifecycle

Fraud and chargeback risk are not evenly distributed across the merchant relationship. They concentrate at two distinct points, and an onboarding program that doesn't account for both has a structural gap.

The first is at application. Synthetic identity attacks, business impersonation fraud, and prohibited business applications are most common when a fraudulent actor is attempting to gain access to the platform. This is where merchant fraud models do their most important work — evaluating the legitimacy of the business itself, not just individual transactions.

The second is in the 60 to 90 days after a merchant begins processing at scale. This is when bust-out fraud — which accounts for 21% of all fraud cases — becomes detectable in transaction data, when merchants that passed underwriting begin misusing the platform, and when early chargeback accumulation signals a portfolio problem before it becomes a card network issue.

A merchant that cleared underwriting cleanly can still generate significant exposure in this window. Transaction monitoring is what catches it — watching payment activity continuously for behavioral shifts that weren't present at onboarding.

The implication is direct: underwriting and transaction monitoring are not redundant controls. They catch different risk patterns at different points in the lifecycle. Programs that rely on underwriting alone — or that run periodic manual reviews rather than continuous monitoring — are structurally exposed in the second window.

‍

What automated onboarding actually looks like in practice

Automation in merchant onboarding is not a single tool. It is a set of connected capabilities that together allow a program to scale volume without scaling manual review proportionally.

Instant data aggregation. Rather than waiting for an analyst to pull business registration data, review a website, check litigation records, and run a fraud model sequentially, an automated system returns all of this in seconds. The analyst — if the case requires one — starts with a complete picture rather than building it from scratch.

Tiered decisioning. Low-risk applications auto-approve. High-risk applications auto-decline or route to a senior reviewer. The middle tier routes to an analyst queue with pre-populated research and a recommended decision. Coris customers running automated underwriting workflows have reduced manual review volume by more than 80%, with the remaining reviews concentrated in cases where human judgment genuinely changes the outcome.

AI agents for end-to-end workflow execution. AI agents go beyond data aggregation to execute the full underwriting workflow: pulling merchant data, applying risk policies, generating a decision, documenting the rationale, and taking action — all without manual intervention for cases that fall within defined parameters.

Weave, a SaaS platform with embedded payments serving small businesses, reclaimed 20 to 40 hours of analyst time per week after deploying automated onboarding workflows. The time savings came from eliminating the manual research and decisioning work on applications that didn't require human judgment.

Audit trails by default. Every automated decision needs documented rationale — for card network inquiries, regulatory review, and internal QA. Platforms that generate audit trails automatically don't require analysts to reconstruct decision history from fragmented logs after the fact.

‍

The MATCH list and what a hit actually means

The MATCH list — Mastercard Alert to Control High-Risk Merchants — is a database of merchants terminated by acquirers for cause. Payment providers are required to check it before onboarding.

A MATCH hit does not automatically mean decline. It means the application requires additional scrutiny. The relevant questions are why the merchant was listed, how long ago, and whether the circumstances that led to the listing are still present or have been resolved. A merchant listed for excessive chargebacks five years ago under different ownership is a different risk than one listed six months ago for fraud.

What a MATCH hit does mean is that the merchant has prior acquiring history that ended badly enough for a prior acquirer to file a termination report. That history needs to be understood and documented before an approval decision is made.

‍

How to evaluate an onboarding program's actual risk coverage

Most payment providers have a clearer picture of their approval rate than their risk coverage. Approval rate is easy to measure. Risk coverage — whether the program is catching the fraud and compliance violations it should be catching — is harder to assess but more important.

What percentage of approved merchants are reviewed for website content before approval? If the answer is "the ones that look suspicious," that's a gap. Website content is where prohibited categories, deceptive practices, and business model mismatches show up. Automated screening closes this gap at scale.

What is the false negative rate on fraud at onboarding? Fraud that passes onboarding appears in chargeback data, dispute rates, and card network monitoring programs months later. Tracing losses back to onboarding decisions reveals whether the fraud model is catching what it should be catching.

How long does it take to approve a clean merchant? If the answer is measured in days, the program has an automation problem, not a risk problem. A low-risk merchant — established business, clean fraud score, no MATCH hits, website content that matches the stated MCC — should be approvable in under two minutes with adequate data aggregation and decisioning infrastructure. If your median approval time for clean merchants is hours or days, that gap is entirely operational. It means analysts are touching cases that don't require human judgment.

What happens to a merchant after approval? If the answer is "they get reviewed when something triggers a manual alert," that's periodic monitoring, not continuous transaction monitoring. The distinction matters for the risk window between reviews — and it's where most programs are most exposed.

‍

Frequently asked questions

What is the difference between a payfac and an ISO for merchant onboarding purposes?

For the ISOs that operate at scale and use merchant risk infrastructure, the practical difference from a payfac is smaller than the industry taxonomy suggests. These ISOs own underwriting liability, manage portfolio risk directly, and absorb exposure when merchants generate chargebacks or commit fraud. Onboarding decisions carry the same weight they do for a payfac.

Where payfacs and ISOs differ is typically in processing structure and how the merchant relationship is set up — not in whether the operator carries risk. Both need rigorous merchant screening at onboarding, continuous portfolio monitoring, and the ability to act quickly when a merchant becomes a problem.

What is tiered underwriting and when should a payfac use it?

Tiered underwriting routes onboarding decisions based on risk score rather than applying the same process to every application. Low-risk merchants — established businesses, clean fraud scores, no MATCH hits, website content that matches the stated MCC — get auto-approved. High-risk applications get declined or routed to senior review. The middle tier gets analyst review with pre-populated research. Tiered underwriting is appropriate for any payfac processing meaningful application volume. At low volume, manual review of every application is manageable. At scale, it isn't — and the operational constraint becomes the bottleneck on growth.

What signals are most predictive of chargeback risk at onboarding?

Prior processing history is the strongest single signal — past chargeback rates predict future ones. For merchants without prior processing history, the next most predictive signals are industry category, business model characteristics (digital goods and subscription businesses carry higher chargeback rates than most physical goods categories), refund policy clarity, and website content quality. Fraud model scores are predictive of application-stage fraud but are less directly predictive of chargeback risk from legitimate businesses.

How should a SaaS platform think about onboarding risk differently than a standalone payfac?

A SaaS platform's merchants are typically its existing software customers. The risk profile of that merchant base is shaped by the vertical the platform serves — a platform serving home services businesses has different risk characteristics than one serving healthcare practices. Programs should be calibrated to that vertical's specific fraud patterns and chargeback tendencies rather than generic risk thresholds. The other meaningful difference is that a SaaS platform's payments conversion is directly tied to onboarding friction. A merchant who abandons payments onboarding is a churn risk for the software product. Approval speed matters more in this context than it does for a standalone payfac where the merchant came specifically for payment processing.

How should a payment provider handle middle-tier merchant applications that don't auto-approve or auto-decline?

The middle tier is where most onboarding programs lose efficiency. Auto-approvals are fast. Auto-declines are fast. Manual review of edge cases is where throughput degrades and analyst judgment is most variable.

The two practices that matter most: first, route middle-tier cases with pre-populated research rather than a blank file. An analyst who opens a case with business registration data, a fraud model score, a website screenshot, litigation results, and a recommended decision already assembled works faster and makes more consistent decisions than one who has to gather that context themselves. Second, define explicit escalation criteria so that middle-tier cases don't sit in a general queue indefinitely. Time-in-queue limits and clear ownership reduce the backlog that builds when edge cases accumulate without resolution paths.

The goal is not to eliminate human judgment from edge cases — it's to make sure human judgment is applied efficiently and consistently when it's actually needed.

What is the relationship between merchant onboarding and card network compliance?

Card networks — Visa and Mastercard primarily — set the compliance standards that govern what payment providers are required to do during onboarding. This includes KYB and KYC requirements, MATCH list checks, prohibited merchant category restrictions, and documentation standards. Payment providers that onboard merchants who violate these standards face fines, increased monitoring, or in severe cases, loss of processing rights. The compliance requirements set a floor; a well-designed onboarding program goes beyond the floor to catch risks that compliance minimums don't address.

‍

Merchant onboarding infrastructure with Coris

Coris provides merchant onboarding infrastructure for ISOs, payfacs, and SaaS platforms with embedded payments — covering merchant intelligence, fraud scoring, automated underwriting workflows, and AI agents that execute risk playbooks end-to-end. The platform currently monitors more than 1 million merchants and $50 billion in annualized transactions.

See how it works →