Home/Research library/Compliance Slows Launches

Guide · Merchant onboarding

Underwriting for Online Merchants

Underwriting for Online Merchants: What PSPs Evaluate Before Approval An online store is more than a sales channel during payment underwriting. It is evidence. The product pages show what the merchant says it sells. The checkout shows what the customer is asked to pay. The terms

Source-imported researchEditorial verification pending

Research draft awaiting independent review. This material was adapted from an existing research library. Provider-specific promotions have been excluded automatically; facts, regulatory requirements, and conclusions must be verified before the page is indexed publicly.

Underwriting for Online Merchants: What PSPs Evaluate Before Approval

An online store is more than a sales channel during payment underwriting.

It is evidence.

The product pages show what the merchant says it sells. The checkout shows what the customer is asked to pay. The terms explain what happens after payment. The delivery policy describes when the merchant promises to perform. The refund and cancellation policies describe what happens when that promise is not fulfilled as expected.

Put together, those elements describe an economic relationship:

Customer sees an offer

→ customer agrees to pay

→ merchant receives a payment obligation

→ merchant delivers a product or service

→ customer accepts the outcome, requests a refund, or disputes the transaction

That relationship is much closer to what a payment underwriter is evaluating than the appearance of the website itself.

Payment underwriting is therefore not simply KYC plus a fraud check.

KYC and KYB can help establish who a person or business is. Underwriting asks a broader question:

What financial, operational, regulatory, fraud, dispute, and fulfilment exposure would processing payments for this merchant create?

Visa's current rules require an acquirer or payment facilitator to conduct due diligence before contracting with a prospective merchant or sponsored merchant, and its merchant qualification standards require an acquirer to consider matters including financial responsibility, permitted jurisdiction and activity that could harm the Visa system or brand.

Mastercard similarly requires an acquirer, before entering into or renewing a merchant agreement, to verify that the merchant is a bona fide business, has safeguards for account data, complies with applicable laws, and is conducting bona fide transactions with cardholders.

Those network obligations help explain why online merchant approval can involve considerably more than confirming that a company was incorporated.

The underwriter is trying to understand the entire promise between merchant and customer.

What is merchant underwriting?

Payment underwriting is the assessment of whether a PSP, acquirer, bank, payment facilitator, or other relevant party is willing to accept the exposure associated with enabling payment processing for a merchant.

Different organizations divide responsibilities differently, so there is no single universal underwriting workflow.

But the underlying questions can include:

Is the merchant a legitimate operating business?

Is its activity supported?

Does the customer-facing business match the application?

What exactly is being sold?

When does the customer pay?

When does the merchant fulfil?

What happens when customers request refunds?

What kinds of disputes could arise?

What fraud exposure exists?

What transaction values and volumes are expected?

Which markets are involved?

What does previous processing performance show, if history exists?

Could the merchant meet customer obligations if refunds or disputes increased?

Does the provider or acquirer have appetite for the resulting relationship?

Not every merchant will be asked every question.

The underwriting scope depends on the business, provider, acquiring arrangement, jurisdictions, payment methods and other circumstances.

KYC and KYB are not the same thing as underwriting

This distinction explains a great deal of merchant frustration.

A merchant completes company verification and assumes:

We passed compliance. Why are they still asking questions?

Because identity verification answers only part of the problem.

KYC and KYB

Broadly concern questions such as:

What legal entity exists?

Who owns or controls it?

Who is acting for it?

Can the relevant identity information be verified?

FATF's customer-due-diligence framework, for example, includes identifying customers and beneficial owners, understanding ownership and control structures, and understanding the purpose and intended nature of a business relationship. How those principles translate into specific legal requirements varies by jurisdiction and institution.

Underwriting

Moves from:

Who is the merchant?

to:

What happens if we process its payments?

A completely legitimate and properly verified company can still require substantial underwriting because its:

Product

Customer relationship

Delivery model

Transaction values

Geography

Payment flow

Refund exposure

create questions independent of identity.

Conversely, being declined by one provider does not necessarily mean the merchant is illegitimate.

The provider or its acquiring partners may simply not support the particular merchant model or exposure.

Why online merchants create particular underwriting questions

With a physical merchant, some aspects of the business can be directly observable at the point of sale.

Online commerce separates:

Customer

Merchant

Payment

Product

Delivery

across systems, locations and time.

The customer can pay without meeting the merchant.

The merchant can receive payment before delivering.

The card can be used without being physically presented.

The customer can buy from another country.

A digital product can be delivered instantly while a physical product can arrive days later and a future service might not be consumed for months.

Those differences mean an online merchant's payment exposure depends heavily on what happens before and after checkout.

That makes the website, customer journey and fulfilment model useful underwriting evidence.

The business: what actually exists behind the checkout?

The first layer of the underwriting picture is the business itself.

The review may need to understand:

Legal entity

Trading name

Products or services

Merchant category

Operating markets

Customer markets

Business model

Relevant licenses where applicable

Settlement relationship

This is different from simply verifying incorporation.

A company can exist legally while the underwriter still needs to understand whether the activity represented in the application matches the business that customers actually encounter.

A useful merchant test is:

If an underwriter saw only our application, our website and our supporting commercial evidence, would all three describe the same business?

If not, expect questions.

The website: evidence of the customer promise

An underwriter is not reviewing your website as a consumer critic.

Page speed, branding and beautiful typography are not the central concern.

The relevant question is:

What does the website reveal about the transaction relationship?

Visa's current electronic-commerce rules provide a concrete example of why customer-facing information matters to card acceptance. Visa requires e-commerce merchant websites or applications to contain specified information such as customer-service contact information, merchant-outlet country information in the checkout sequence, an address for correspondence and information concerning delivery of multiple shipments.

Those are network requirements, not a universal PSP underwriting checklist. But they demonstrate an important principle:

The customer-facing site is part of the payment relationship.

An underwriting review may therefore compare the site against the merchant application.

Potential questions include:

Does the site's legal or trading identity make sense?

Is it clear what customers purchase?

Are prices and currencies understandable?

Are material recurring terms disclosed?

Are delivery expectations understandable?

Can customers find refund or cancellation information?

Is customer support identifiable?

Does the country footprint match the application?

Does the site contain products or activities not disclosed during onboarding?

The goal is not to create a website “for the underwriter.”

It is to ensure that the website accurately represents the real business.

Technical website quality vs underwriting relevance

A technically imperfect website is not automatically an underwriting problem.

Likewise, a beautiful website does not prove a strong merchant relationship.

Separate:

Technical quality

Examples:

Load performance

CSS

responsive design

SEO

animations

from:

Underwriting-relevant information

Examples:

Merchant identity

Product

Pricing

payment relationship

delivery

customer support

refund/cancellation terms

geographic activity

The second category helps explain the obligations a customer accepts when paying.

That is what makes it useful to the underwriting process.

The product: what is the customer actually buying?

Products create different payment exposures.

Consider the difference between:

Digital access delivered immediately

and:

Furniture manufactured after payment and delivered eight weeks later.

Both may be perfectly legitimate online businesses.

But the relationship between:

payment

and:

fulfilment

is different.

Other business models introduce their own questions.

Physical ecommerce

Relevant characteristics can include:

Inventory

Supplier relationships

Delivery

Shipping time

Returns

Digital goods

Questions can include:

How access is granted

How fulfilment is recorded

Account security

Fraud and disputes

Subscriptions

Relevant characteristics can include:

Initial payment

Recurring charges

Trial conversion

Cancellation

Refunds

Customer disclosures

Future services

For travel, events, education or other future delivery, the customer may pay materially before the merchant completes the obligation.

Marketplaces and platforms

The review may need to understand:

Who sells

Who collects

Who fulfils

Who refunds

Whether third parties receive funds

These are examples of underwriting questions, not universal provider requirements.

The point is:

“Ecommerce merchant” is not a sufficient description of the payment model.

The customer promise: what does paying obligate the merchant to do?

This is the conceptual center of online merchant underwriting.

Every successful order creates a merchant-side obligation.

The customer pays because the merchant has promised something.

That promise might be:

Ship this product tomorrow.

Or:

Give me software access for the next month.

Or:

Let me use this digital item immediately.

Or:

Reserve a service for me six months from now.

The underwriter may therefore want to understand:

Payment date

→ merchant obligation exists

→ fulfilment occurs

→ customer obligation is satisfied

The longer, larger or less predictable the exposure between those stages, the more there may be to understand.

That does not mean long fulfilment automatically makes a merchant unacceptable.

It means fulfilment timing can be relevant to the financial exposure surrounding the payment.

The payment flow: who pays whom, when, and for what?

Online businesses can make the payment relationship surprisingly difficult to infer.

For a straightforward merchant:

Customer

→ pays merchant

→ merchant fulfils order.

But a platform might instead involve:

Buyer

→ platform

→ third-party seller

→ customer fulfilment.

A subscription might involve:

Initial customer-authorized payment

→ recurring relationship

→ subsequent charges.

A merchant can also have:

Deposits

Partial payments

Preorders

Split fulfilment

Delayed capture

Installments

Recurring billing

Marketplace payments

Underwriters need the actual payment flow because economic liability follows the real transaction, not the merchant's preferred shorthand description.

For unusual models, a simple flow diagram can sometimes communicate more than several paragraphs:

CUSTOMER

| payment

MERCHANT / PLATFORM

| product or service obligation

FULFILMENT

CUSTOMER OUTCOME

For a marketplace, add the seller and funds flow explicitly.

Fulfilment: what happens after the merchant has the order?

For many online merchants, underwriting cannot stop at checkout because checkout is where the merchant's obligation begins.

An underwriter may want to understand whether the merchant can reasonably deliver what it sells.

Possible evidence, depending on the business model, might include:

Shipping records

Tracking

Delivery confirmations

Digital delivery logs

Service completion records

Booking records

Warehouse information

Historical order records

The correct evidence varies significantly by merchant.

The question behind it is:

Can this merchant fulfil the customer obligations created by payment?

This is the territory of the dedicated Proof of Fulfilment Requirements article; the important underwriting principle here is simply that payment and delivery are economically connected.

Supply and fulfilment are different questions

For a physical-goods merchant:

Supply asks:

Can the merchant obtain the product?

Fulfilment asks:

Can the merchant deliver it to the customer?

A supplier contract might help explain the first.

A tracking record might help explain the second.

Neither automatically proves everything about the other.

That distinction is why an underwriter may sometimes request more than one type of commercial evidence.

The dedicated Supplier Agreement Requirements article should own the deeper supply-evidence discussion.

Refunds: the merchant voluntarily reverses the customer payment relationship

Refunds deserve separate treatment from disputes.

A refund usually begins within the merchant/customer relationship.

A customer asks for money back and the merchant processes the return according to its policies and applicable obligations.

Underwriting interest may arise because refund behavior can reveal things about:

Product expectations

Fulfilment

Customer satisfaction

Cancellation behavior

Operational capacity

Do not interpret every refund as a sign of fraud or poor merchant quality.

Some businesses naturally have different refund patterns.

The important question is whether the refund profile is understandable in the context of the business.

Refund risk is not dispute risk

These concepts should not be combined.

Refund

Merchant returns money according to the relevant customer relationship.

Dispute or chargeback

The cardholder challenges a transaction through an issuer/network process.

A customer might dispute because they:

Do not recognize the transaction

Claim the product was not delivered

Contest cancellation

Contest the transaction for another applicable reason

The exact dispute framework depends on payment method and network.

An underwriter therefore may examine refunds and disputes separately.

A merchant with low refunds does not necessarily have low disputes.

And a high refund volume does not automatically indicate fraud.

Fraud risk is also different from chargeback risk

Fraud concerns whether the transaction or customer interaction is illegitimate or abusive.

A chargeback is a payment dispute outcome/process.

Fraud can produce chargebacks.

So can non-fraud problems such as:

Fulfilment disagreements

Cancellation disputes

Transaction-recognition problems

Keeping the concepts separate helps merchants explain their payment history more precisely.

Instead of saying:

Our chargebacks are fraud.

or:

Our fraud rate is our chargeback rate.

identify what the available data actually measures.

Historical processing: what happened when real customers paid before?

For an established merchant, processing history can turn underwriting from projection into evidence.

Potential information may include:

Processed value

Transaction count

Average transaction value

Refund activity

Dispute activity

Fraud indicators

Customer geography

Currency

Seasonality

Growth

The strongest analysis uses clearly defined periods and denominators.

For example:

Refund rate by value

Refunded transaction value during defined period

÷ relevant processed payment value during the defined period

Dispute rate

The exact denominator should be defined and should match the metric being discussed.

Do not present a percentage without explaining:

Time period

Entity

Transaction population

Whether it measures count or value

And do not invent universal acceptable thresholds.

Providers, acquirers, payment methods and jurisdictions can use different criteria.

What if the merchant has no processing history?

A new merchant cannot provide historical PSP performance it does not have.

That does not mean underwriting is impossible.

It means the reviewer may need other evidence to understand the business.

Depending on the case, that could include:

Operating history

Existing sales

Contracts

Fulfilment capability

Supplier relationships

Financial information

Funding

Forecast assumptions

Operational capacity

The distinction is:

No payment-processing history

is not the same thing as:

No evidence that a viable operating business exists.

The dedicated Processing History Requirements article should explain this problem in depth.

Geography can change the underwriting picture

Online merchants frequently sell beyond the country where their company is incorporated.

That introduces several different geographic dimensions:

Merchant entity country

Customer country

Acquiring market

Settlement country

Payment-method market

Fulfilment origin

Supplier country

These should not be collapsed into:

“We are global.”

An underwriter may need to understand where the actual activity occurs and whether the proposed configuration is supported.

Visa's current rules, for example, explicitly require prospective merchants to be operating within an allowed jurisdiction and contain detailed merchant-location requirements.

That does not mean Visa's specific rule structure defines every PSP's onboarding process.

It does show why geography can be part of merchant acceptance rather than simply a marketing choice.

Growth can turn yesterday's merchant into a different underwriting exposure

Suppose an established online merchant processed:

$200,000 per month

and expects:

$2 million per month

after a major launch.

Those numbers are hypothetical.

The underwriting question is not merely:

Is $2 million too high?

It is:

What causes the increase?

Does current sales activity support the expectation?

Can supply expand?

Can fulfilment expand?

Can customer support expand?

Does the transaction profile change?

Are new countries involved?

Does the merchant have sufficient operational and financial capacity for the larger customer obligation?

Rapid growth is not automatically negative.

But a forecast materially different from historical activity needs explanation.

The dedicated Underwriting for High-Growth Merchants article should own that analysis.

The Online Merchant Underwriting Map

A useful way for merchants to prepare is to evaluate the business in the same order that the customer relationship develops.

Layer 1 — Business

Underwriting question

Who is selling, and is the merchant relationship legitimate and eligible?

Potential evidence:

Entity

Ownership

Website

Business description

Merchant category

Geography

Licensing where applicable

Layer 2 — Customer promise

Underwriting question

What does the customer believe they are buying?

Look at:

Product/service

Pricing

Currency

Terms

Subscription conditions

Cancellation

Refund policy

Layer 3 — Payment

Underwriting question

How does the customer obligation become a financial transaction?

Understand:

Transaction amount

Timing

Payment method

Recurring relationship

Deposits

Prepayment

Marketplace/platform flows

Customer authentication where relevant

Layer 4 — Fulfilment

Underwriting question

How and when does the merchant satisfy the obligation created at payment?

Understand:

Supplier

Inventory

Delivery

Digital fulfilment

Service completion

Time to fulfil

Layer 5 — Customer outcomes

Underwriting question

What happens when the transaction does not end normally?

Understand:

Cancellation

Refund

Complaints

Disputes

Fraud

Customer support

Layer 6 — Financial exposure

Underwriting question

What happens financially if the merchant's assumptions fail?

Potential dimensions:

Transaction value

Volume

Refunds

Disputes

Fulfilment delay

Growth

Geography

Historical performance

Financial/operational capacity

Online Merchant Underwriting Map — compact view

Layer

Core question

Example evidence or information

Business

Who is the merchant and what does it actually do?

Entity, ownership, website, product, geography

Customer promise

What is the customer promised before paying?

Product pages, price, terms, cancellation/refund policy

Payment

How does money move?

Transaction flow, amount, recurring model, payment methods

Fulfilment

How is the promise completed?

Shipping, digital delivery, service records, supplier model

Customer outcomes

What happens when something goes wrong?

Refunds, complaints, disputes, fraud controls

Financial exposure

What obligations could remain if the merchant cannot perform?

Volume, ticket size, history, timing, growth, financial capacity

This is an analytical framework, not a universal PSP checklist.

How online merchants should prepare for underwriting

The objective is not to learn how to “pass” underwriting.

It is to make the real business easy to understand and substantiate.

Make the application and website tell the same story

Check:

Legal/trading identity

Products

Pricing

Markets

Subscription model

Delivery

Refunds

If something differs, explain why.

Describe the customer-payment lifecycle

Document:

What customer buys

→ when customer pays

→ who receives the payment

→ how merchant fulfils

→ what happens if customer cancels or requests a refund.

Do not assume the reviewer will infer an unusual model.

Know your payment numbers

Where available, prepare clearly defined:

Monthly processed value

Transaction count

Average ticket

Refund volume/rate

Dispute volume/rate

Geography

Growth

Use the correct legal entity and reporting period.

Understand your payment-to-fulfilment interval

Know approximately:

When customer pays

When fulfilment starts

When fulfilment completes

Which evidence records completion

This can be especially important when payment substantially precedes delivery.

Prepare relevant supply and fulfilment evidence

Where appropriate, identify:

Suppliers

Inventory relationships

Shipping

Digital fulfilment

Service completion

Do not overwhelm the PSP with unrelated files.

Understand what question each piece of evidence answers.

Explain abnormal numbers rather than hiding them

If:

Sales increased sharply

Refunds temporarily increased

A new market changed transaction mix

The business changed product

Historical processing belongs to another group entity

explain the context accurately.

An unexplained inconsistency generally creates more work than a disclosed, supportable business change.

Review customer-facing policies before applying

Check whether:

Products are described accurately

Pricing is understandable

Customer support is reachable

Delivery expectations are clear

Refund/cancellation information reflects actual operations

Recurring-payment terms reflect the real billing model

Do this because those policies define the customer relationship—not merely because an underwriter might look at them.

What underwriting cannot be reduced to

Online merchant underwriting is not just:

A credit check

Financial capacity may matter in some cases, but underwriting is broader.

A fraud check

Fraud is one type of exposure.

KYC/KYB

Identity verification answers different questions.

A website inspection

The website is evidence of the commercial relationship.

A chargeback threshold

Historical dispute behavior may matter, but no single metric universally determines acceptance.

A morality score for the merchant

A legitimate company can fall outside one provider's supported geography, acquiring model, payment flow, category or risk appetite.

That is a provider-fit question, not necessarily a statement about the business's legitimacy.

Why two PSPs can reach different underwriting decisions

A merchant can submit essentially the same business to two providers and receive different outcomes.

Possible reasons include differences in:

Acquiring relationships

Supported countries

Merchant categories

Payment methods

Settlement structure

Risk appetite

Product capabilities

Commercial model

Approval by Provider A therefore does not compel approval by Provider B.

Likewise, rejection by Provider B does not establish that Provider A should reject the merchant.

This is why merchants should distinguish:

merchant quality

from:

provider fit.

The dedicated Why Merchants Are Rejected by PSPs article should develop that distinction further.

The broader positioning opportunity is to help merchants understand that payment approval and technical integration are connected to the real commercial relationship behind the checkout.

The merchant's best underwriting preparation is accuracy

An online merchant should not prepare for underwriting by asking:

What do we need to say to get approved?

It should ask:

Can another party understand, from the evidence we provide, exactly what happens from the moment a customer sees our offer to the moment that customer has either received what was promised or had the payment relationship resolved?

That means understanding six things:

The business.

The customer promise.

The payment.

The fulfilment.

The customer outcome.

The financial exposure.

When those relationships are clear, the underwriter can evaluate the actual merchant rather than trying to reconstruct the business from contradictions, missing information or assumptions.

Preparation cannot guarantee approval.

It can remove avoidable uncertainty.

And that is the most useful way to think about underwriting for online merchants: not as a mysterious risk score behind a PSP application, but as an assessment of whether the complete customer-payment promise creates a merchant relationship the relevant provider and acquiring parties are prepared to support.

This article provides general information and does not constitute legal, regulatory, financial, tax, or compliance advice. Merchant onboarding and underwriting requirements vary by jurisdiction, provider, acquirer, business model, and individual circumstances. Merchants should confirm applicable requirements with qualified advisers and the relevant payment providers, acquirers, banks, regulators, and authorities.

🙂 🙂 🙂 🙂 🙂 🙂 🙂

The brief positions this as the cluster’s general underwriting logic article: it should explain what an underwriter is trying to understand about an online merchant rather than becoming another onboarding-process or document-checklist article. The strongest differentiator is the brief’s “customer promise” concept: the website matters because it is evidence of what customers are being promised before money changes hands.

SEO & EDITORIAL RECOMMENDATIONS

Underwriting for Online Merchants: What PSPs Evaluate

This keeps the primary phrase intact while creating a concise SERP title.

Meta title

Underwriting for Online Merchants | PSP Approval Guide

Meta description

Learn what PSPs and acquirers may evaluate when underwriting online merchants, including websites, products, payment flows, fulfilment, refunds, disputes, processing history and financial exposure.

Suggested URL slug

/underwriting-for-online-merchants/

underwriting for online merchants

Secondary keyword priorities

Use naturally:

ecommerce merchant underwriting

PSP underwriting process

online merchant approval

merchant account underwriting

payment processor underwriting

ecommerce PSP approval

website underwriting merchant account

Additional semantic opportunities:

merchant underwriting process

ecommerce underwriting

what PSPs check

merchant account approval

payment processing underwriting

online business underwriting

ecommerce merchant approval

Featured-snippet opportunity

A short definition immediately beneath the introduction could be visually highlighted:

Online merchant underwriting is the assessment of the financial, operational, regulatory, fraud, dispute and fulfilment exposure associated with processing payments for an ecommerce or other online business. It goes beyond KYC/KYB by examining how the merchant sells, charges customers, fulfils orders, handles refunds and disputes, and supports its payment obligations.

This directly targets definition-oriented search intent.

Strongest information-gain angle

The article should resist becoming a list such as:

“10 things payment processors check.”

The customer-promise lifecycle is considerably stronger:

Offer → payment → obligation → fulfilment → refund/dispute → financial exposure

That gives the piece a conceptual model competitors are less likely to have and differentiates it from:

onboarding-process articles

document checklists

KYC/KYB explanations

high-risk merchant articles

Need help narrowing down payment options?

Answer a few questions about your business and compare the capabilities that matter to you.

Explore matching options ↗