Payment Compliance for Marketplaces

Payment Compliance for Marketplaces: Why Multi-Party Funds Flow Changes Merchant Underwriting

A customer pays $100 through a marketplace.

That sounds like one payment. From a compliance and underwriting perspective, it can represent several different relationships.

Who sold the product?

Who accepted the customer's $100?

Who becomes economically entitled to it?

Who decides how much of that $100 the seller receives?

Who returns the customer's money if the order is refunded?

Who absorbs the financial consequence if the payment is disputed?

Until those questions are answered, “marketplace” is not a complete payment model.

That is why payment compliance for marketplaces begins with the funds flow and participant roles, not with a generic seller-onboarding checklist.

A conventional ecommerce merchant commonly sells its own product, accepts payment for its own account, fulfills the transaction, handles the refund, and receives the resulting settlement.

A marketplace introduces at least one additional commercial party: the seller. Once that happens, payment underwriting must understand not simply the platform company but the relationship among the buyer, seller, platform, payment provider, collecting entity, and payout recipient.

In some payment-network models, marketplaces are explicitly treated differently from ordinary merchants. Mastercard's current June 2026 rules, for example, contain specific requirements for a “Platform Merchant” hosting third-party sellers, including seller due diligence, seller agreements, ongoing monitoring, and dispute responsibility under that model. Visa likewise maintains separate marketplace and third-party-agent risk standards.

The practical consequence is simple:

Before a marketplace asks, “What compliance documents do our sellers need?” it should be able to explain exactly how commerce and money move through the platform.

A marketplace is not simply an ecommerce merchant with multiple sellers

The difference is structural.

A standard direct merchant often looks roughly like this:

Customer

→ buys from merchant

→ merchant collects payment

→ merchant fulfills

→ merchant receives settlement

→ merchant handles refund or dispute.

A marketplace can instead look like:

Buyer

→ purchases from Seller A

→ payment enters a platform-controlled checkout

→ a designated merchant or collecting entity accepts the card transaction

→ platform records Seller A's entitlement

→ platform or payment partner calculates deductions

→ Seller A receives a payout later.

The buyer may experience that as one checkout.

The payment provider sees multiple economic relationships.

That creates questions about:

•seller identity;

•seller business activity;

•payment acceptance;

•merchant classification;

•prohibited or restricted categories;

•settlement;

•payout destinations;

•refund liability;

•dispute liability;

•transaction monitoring;

•country coverage;

•potentially regulated handling of funds.

Those questions cannot be resolved by knowing only that the platform's own corporate KYB has passed.

[Internal link opportunity: KYC and KYB]

Start with the Marketplace Compliance & Funds-Flow Map

Before writing policies, map the transaction.

A useful marketplace model begins with:

•Buyer

Who purchases the product or service?

Determine:

•whether buyers are consumers or businesses;

•which countries they can come from;

•which payment methods they use;

•whom they believe they are buying from.

•Seller

Who actually provides the goods or services?

Determine:

•whether the seller is an individual or business;

•what category of goods or services it offers;

•where it operates;

•which entity has contracted with it;

•whether the platform can suspend or remove it.

•Checkout and payment acceptance

Who is presented to the payment system as accepting the transaction?

This is where vague phrases such as:

“The marketplace processes the payment”

become inadequate.

A PSP processes payments technically.

A marketplace can have a different commercial role.

An acquirer has another role.

A Merchant of Record, where one is genuinely part of the model, has another.

Those terms should not be treated as synonyms.

•Collecting entity

Which entity actually receives or controls the incoming payment proceeds under the payment-provider structure?

That may be:

•the marketplace;

•a PSP or regulated payment institution;

•a Merchant of Record;

•another contractually designated entity.

The answer can materially change the regulatory and underwriting analysis.

•Seller entitlement

How does the system determine what belongs to each seller?

A $100 customer transaction might conceptually produce:

$100 customer payment

minus marketplace commission

minus transaction charges where applicable

minus seller-specific adjustments

equals seller entitlement.

That accounting allocation should be distinguished from the actual legal and regulated movement of funds.

•Seller payout

Who sends money to the seller?

Determine:

•payout provider;

•payout account owner;

•payout destination;

•payout country;

•timing;

•any reserves or adjustments;

•what happens when the payout fails.

Collection and payout are separate payment events.

•Refund and dispute

If the $100 transaction is refunded:

Who is obligated to the buyer?

If the buyer disputes the transaction:

Which participant bears the financial consequence?

These answers are part of the payment model—not merely customer-service policy.

Collection and payout are different compliance questions

This distinction matters because marketplaces often describe them as one feature:

“We collect customer payments and pay our sellers.”

That sentence compresses two different flows.

Collection

Buyer → payment acceptance → collecting/settlement structure

Questions include:

•who is the merchant in the acquiring arrangement;

•who appears in transaction data;

•which goods or services are being sold;

•who bears customer-facing transaction responsibility.

Payout

Platform entitlement calculation → seller → seller's financial account

Questions include:

•who is the recipient;

•how the recipient is identified;

•whether the payout account belongs to the seller;

•where the recipient is located;

•which payout rail is used;

•whether the payout arrangement creates additional regulated or provider requirements.

A platform can have a perfectly clear card-acceptance integration while still having an unresolved payout model.

The reverse can also occur.

That is why International Payouts deserves separate treatment rather than being reduced to a marketplace-onboarding subtopic.

[Internal link opportunity: International Payouts]

Receiving buyer funds can change the regulatory analysis

Marketplaces should be particularly careful about statements such as:

“We take the buyer's money, hold it, and then send it to sellers.”

In some jurisdictions, those facts can raise payment-services or money-transmission questions.

The UK's Financial Conduct Authority specifically tells online marketplaces and businesses bringing buyers and sellers together to consider whether they provide payment services. The FCA notes that a business receiving customer money before passing it to a seller may be providing a regulated payment service, depending on the circumstances and available exclusions.

The analysis is not identical in every country.

In the United States, FinCEN's federal money-transmitter framework is also fact-specific. FinCEN has recognized defined payment-processing and “integral to the sale” situations that do not constitute money transmission, but its rulings depend on the exact arrangement and should not be converted into a blanket marketplace exemption.

This is the important operational lesson:

Do not decide the regulatory status of a marketplace by describing the user interface. Determine who accepts, controls, and transmits the funds under the actual contractual and payment structure.

That analysis can require specialist legal advice before the payment integration is finalized.

Seller verification is different from buyer verification

Marketplaces also introduce a second population.

Buyer verification

Buyer-side controls may be related to:

•payment authentication;

•fraud controls;

•sanctions or other compliance checks where applicable;

•account-security requirements.

Seller verification

Seller-side review asks a different set of questions:

Who is receiving economic value through the platform?

What business does that seller actually operate?

What is being offered for sale?

Where should the seller's funds be paid?

Is the seller still operating within the category originally approved?

Exact legal KYC/KYB obligations depend on the marketplace structure, provider, jurisdiction, and regulated roles involved.

But card-network and acquiring models can independently require meaningful seller due diligence.

Mastercard's current Platform Merchant rules, for example, require that covered platform merchants maintain procedures for collecting and verifying information about third-party sellers and their principal owners, enter into seller contracts, and monitor seller activity.

Visa's acceptance-risk framework likewise places marketplace structures inside a specific third-party risk model and requires acquirer oversight of marketplaces and their underlying retailers under its applicable program rules.

The implication is not:

“Every marketplace everywhere must perform identical KYB.”

It is:

Seller onboarding is part of the payment architecture and needs to be mapped to the marketplace's actual regulatory, network, acquirer, and provider model.

Seller onboarding should answer more than “Who are you?”

Identity is only the first layer.

A marketplace's seller review can need to establish:

Seller identity

Who is the person or legal entity?

Seller ownership

Where relevant, who owns or controls the business?

Seller category

What does the seller actually sell?

Geographic footprint

Where is the seller located and where will it conduct business?

Payout destination

Where will seller proceeds be sent, and does the destination correspond appropriately to the approved seller relationship?

Product permissions

Is the seller's actual inventory permitted by:

•the platform;

•the PSP/acquirer;

•the card network;

•applicable law?

Ongoing consistency

Does the seller continue to sell the activity it was approved for?

That last question is especially important.

A platform can correctly onboard a seller that initially offers ordinary consumer electronics and still acquire new payment risk if that seller later changes what it lists.

Seller approval is therefore not merely a one-time identity event.

The platform's category controls affect underwriting

Marketplace compliance cannot be separated from what sellers are allowed to sell.

Consider two platforms with identical payment flows.

Marketplace A

Allows only:

•books;

•ordinary apparel;

•home goods.

Marketplace B

Allows thousands of loosely categorized third-party listings across products that may include regulated, restricted, or higher-risk categories depending on jurisdiction.

Calling both businesses “marketplaces” does not tell an acquirer enough.

The underwriting question is:

How much control does the platform have over what enters the payment system?

Relevant controls can include:

•approved category taxonomy;

•restricted-product policy;

•seller declarations;

•listing review;

•automated category detection;

•escalation;

•seller suspension;

•ongoing website or listing monitoring.

These controls are not simply fraud controls.

Transaction fraud asks whether a payment is fraudulent.

Marketplace business-model compliance asks whether the underlying seller and transaction should be supported in the first place.

[Internal link opportunity: Marketplace Fraud]

Marketplace compliance is not the same as transaction fraud

This distinction deserves explicit treatment.

Suppose the buyer is genuine.

The card is genuine.

The transaction was authorized correctly.

There can still be a marketplace compliance problem if:

•the seller is not the seller the platform thought it onboarded;

•the seller changed into a restricted business category;

•the listed product is unsupported;

•funds are being paid to an unapproved destination;

•seller geography changed;

•the platform's funds flow no longer matches its approved underwriting model.

Fraud systems can identify suspicious payment behavior.

They do not establish the complete legitimacy or supportability of the seller business model.

Marketplace underwriting therefore operates at two levels:

Transaction-level risk

Is this specific payment likely legitimate?

Participant/business-model risk

Is this seller, product, geography, and funds flow one the payment ecosystem has agreed to support?

Both matter.

They are different problems.

Merchant of Record and PSP are not the same role

Marketplaces frequently use Merchant of Record loosely.

That creates avoidable confusion.

A PSP provides payment services.

A Merchant of Record arrangement, where genuinely implemented, concerns which entity contracts for or assumes specified customer-facing commercial/payment responsibilities under that structure.

The exact responsibilities can include some combination of:

•customer contracting;

•payment acceptance;

•refunds;

•disputes;

•tax;

•invoicing;

•consumer support.

But the label alone does not prove that every one of those obligations has transferred.

A marketplace should therefore avoid telling an underwriter:

“Our PSP is the Merchant of Record”

unless that accurately reflects the contractual structure.

Instead map the obligations individually:

Question

Responsible party

Who sells to the customer?

Defined by marketplace model

Who is merchant in the acquiring structure?

Confirm with PSP/acquirer

Who collects the payment?

Confirm payment flow

Who owes seller proceeds?

Confirm platform/seller contract

Who sends payout?

Confirm payout provider/model

Who refunds the buyer?

Confirm customer terms/payment structure

Who absorbs disputes?

Confirm acquiring/network/contractual allocation

Who handles transaction tax?

Separate tax analysis

Who performs seller verification?

Depends on model and applicable rules

The purpose is not to force every marketplace into one structure.

It is to eliminate ambiguity.

Refund ownership exposes the real marketplace model

Refunds are a useful test because they force the platform to answer questions that may remain hidden during a successful payment.

Suppose:

Buyer pays $100

→ seller becomes entitled to $80

→ marketplace earns $20

→ seller is paid the $80

→ buyer then receives a $100 refund.

Who supplies the $100?

Can the marketplace recover $80 from the seller?

What if the seller has already withdrawn the funds?

What if the seller account is closed?

What if several hundred buyers request refunds at once?

The answers define:

•seller receivables;

•negative balances;

•reserves;

•working-capital exposure;

•platform loss exposure.

This is one reason marketplace underwriting can include financial and operational questions that a simple direct merchant may not face to the same degree.

Chargebacks reveal another layer of liability

A buyer may dispute the card transaction after the seller has been paid.

That creates two separate relationships:

Buyer / card transaction

and

Marketplace / seller payout

The platform cannot assume that because the seller caused the underlying customer problem, the card-network financial consequence automatically moves directly to the seller.

Under particular network marketplace models, the platform can carry explicit responsibility. Visa's marketplace standards, for example, require its covered marketplace agreements to assign the marketplace financial responsibility for transactions processed on behalf of retailers and responsibility for retailer-caused cardholder disputes.

The exact allocation must be confirmed for the marketplace's PSP, acquirer, network, and contractual structure.

For underwriting, the important question is:

If the customer gets the money back after the seller has been paid, who is economically exposed?

That is payout risk.

The payout destination is part of seller risk

Seller approval should connect to the destination receiving seller proceeds.

A platform that verifies Seller A but permits payouts to unrelated Party B without a defined business reason creates a different risk model from one in which payout destinations are controlled and changes are reviewed.

Operational questions can include:

•Can sellers change payout accounts?

•What verification occurs when they do?

•Can one payout account receive funds for many unrelated sellers?

•Can one seller maintain multiple payout destinations?

•Are cross-border payouts supported?

•What happens when destination country changes?

•Is a changed payout destination a review trigger?

The correct controls depend on the payment-provider and payout model.

The point is that seller verification and payout configuration should not exist as unrelated systems.

Geographic expansion multiplies marketplace roles

International expansion is particularly important for marketplaces because “we are launching in Country X” can describe several different changes.

New buyer country

The same sellers begin accepting customers somewhere new.

New seller country

The platform begins onboarding sellers located in a new jurisdiction.

New marketplace entity

A regional legal entity becomes part of the payment flow.

New acquiring region

Card acceptance is routed through a different acquiring arrangement.

New payout corridor

Seller proceeds begin flowing to a new country or through another payment rail.

Those changes do not have the same underwriting consequence.

Current Visa merchant-location standards, for example, contain specific marketplace location and cross-border acquiring concepts rather than treating location as merely the buyer's checkout country.

A scalable marketplace should therefore record geography at multiple levels:

buyer country

seller country

marketplace entity

acquirer

payout destination

rather than storing one field labeled simply market.

[Internal link opportunity: Geographic Expansion Re-Underwriting]

Seller mix can change a marketplace's risk classification

A marketplace may begin with one seller population and evolve into another.

For example:

Original model

→ professional-services sellers

later becomes:

→ professional services

→ digital goods

→ travel services

→ other categories.

The corporate marketplace entity may not have changed.

Its payment risk has.

This is why a “high-risk merchant” label should never be treated as a universal legal category.

A PSP, acquirer, network program, or other participant may assess marketplace risk based partly on:

•seller categories;

•dispute exposure;

•fulfillment;

•geography;

•financial stability;

•third-party controls;

•regulated activities.

A business can therefore move into a different underwriting profile because its seller population changed, even though its platform software remained identical.

[Internal link opportunity: High-Risk Merchant Classification]

What an underwriter needs to understand

Marketplace underwriting becomes much easier when the business can answer the fundamental questions in one consistent package.

Commercial model

•What exactly does the platform enable customers to buy?

•Who legally provides the product or service?

•How does the platform earn revenue?

Seller model

•Who can become a seller?

•How are sellers verified?

•What categories can they sell?

•How are category changes controlled?

Payment model

•Who is identified as the merchant for payment acceptance?

•Who collects the customer's funds?

•Which PSP and acquirer participate?

Funds allocation

•How is the seller entitlement calculated?

•When does it become payable?

•Who controls adjustments?

Payout model

•Who makes the payout?

•Which destinations and countries are supported?

•What happens when a payout account changes?

Refund and dispute model

•Who owes the customer?

•Who initiates refunds?

•Who funds them?

•Who is exposed if the seller cannot repay a negative balance?

Geographic model

•Where are buyers?

•Where are sellers?

•Which marketplace entity is involved?

•Where does acquiring occur?

•Where are payouts sent?

Regulatory model

•Does the platform itself receive or control customer money?

•Is a regulated payment provider performing that function?

•Does the structure create licensing or registration questions in the relevant jurisdictions?

This is the real marketplace underwriting file.

A corporate certificate and beneficial-owner register cannot answer these questions.

Evidence that can make marketplace review easier

There is no universal marketplace evidence pack, but useful material can include:

Funds-flow diagram

Showing collection, ledger allocation, refund, dispute, and payout.

Participant responsibility matrix

Showing buyer, seller, platform, PSP/acquirer, and other roles.

Seller onboarding procedure

Showing identification, business classification, approval, and payout setup.

Seller agreement

Showing the legal relationship and relevant payment obligations.

Permitted and restricted category policy

Showing what sellers are allowed to offer.

Refund and cancellation policy

Showing customer-facing responsibility.

Payout controls

Showing how payout destinations are established and changed.

Current seller mix

Showing categories and geographies actually operating on the platform.

Processing history

Where relevant, showing volume, refunds, and disputes.

Licensing or regulatory analysis

Where the marketplace's funds-control or product model creates that question.

These documents do not guarantee approval.

They reduce ambiguity.

The marketplace launch critical path

The wrong sequence is:

Build marketplace

→ onboard sellers

→ announce launch

→ integrate payments

→ explain the funds flow to compliance

→ discover the structure needs to change.

The better sequence is:

Define buyer/seller relationship

→ draw funds flow

→ assign payment roles

→ determine seller-onboarding model

→ determine product/category controls

→ confirm payment-services and acquiring structure

→ define refund/dispute exposure

→ confirm payout model

→ verify country overlays

→ complete provider underwriting

→ launch.

The technical integration may be only one step in that chain.

If the collecting entity, seller relationship, or payout model is unresolved, API readiness does not make the marketplace payment-ready.

Key takeaway

A marketplace is not simply an ecommerce merchant with more SKUs.

It introduces independent economic participants whose actions can change:

•what is being sold;

•who is being paid;

•where value moves;

•who bears customer obligations;

•which business categories enter the payment system;

•which countries participate;

•who absorbs financial loss.

That is why payment compliance for marketplaces starts with participant roles and funds flow.

For every customer payment, the marketplace should be able to answer:

Who sold?

Who collected?

Who became entitled to the money?

Who paid the seller?

Who refunds?

Who bears the dispute?

Who approved and monitors the seller?

Which legal entities and countries are involved?

If those answers are unclear, the compliance problem is not missing paperwork.

The business model itself has not yet been described precisely enough to underwrite.

A mature marketplace therefore treats its funds-flow diagram as part of its payment architecture, not as a compliance illustration created after the fact.

Draw the money first.

Assign every obligation.

Then determine which regulatory, network, acquirer, PSP, seller-onboarding, and monitoring requirements attach to the actual structure.

That is how a marketplace prevents multi-party payment ambiguity from becoming a launch-stage blocker.

This article provides general information and does not constitute legal, regulatory, compliance, tax, accounting, or financial advice. Requirements vary by jurisdiction, business model, licensing status, payment provider, acquirer, payment method, and merchant risk profile. Merchants should verify current requirements with qualified advisers, relevant authorities, and their payment providers or acquirers.

🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂

A. Brief interpretation

Article-owned question: What changes about payment compliance and underwriting when a business enables third-party sellers and routes money between buyers, a platform, and those sellers?

Business-model characteristic: Multi-party commerce. The platform is not simply selling its own inventory; buyer, seller, platform, PSP/acquirer, and sometimes a Merchant of Record or other intermediary can occupy different legal and payment roles.

Compliance/underwriting concern: The provider cannot underwrite the marketplace until it understands who sells, who accepts the payment, who becomes entitled to the funds, who controls seller admission, who executes refunds, who absorbs disputes, and who receives payouts.

Evidence required: A funds-flow diagram, participant/role matrix, seller-onboarding process, permitted-category controls, payout design, refund/dispute allocation, legal agreements, target-country matrix, and—where relevant—licensing or regulated-payment analysis.

Editorial position: Draw the funds flow before describing marketplace compliance in prose.

Common assumption challenged: “A marketplace is simply an ecommerce merchant with multiple sellers.”

Final merchant decision: Can the marketplace explain exactly who owns every commercial and payment obligation from buyer checkout through seller payout?

This interpretation follows the supplied Business-Model Compliance brief and its requirement that this page own third-party commerce and multi-party funds flow.

B. Publication-ready article

C. Original article asset: Marketplace Compliance & Funds-Flow Map

I would make this the signature visual for the article.

BUYER

│

│ $100 checkout

▼

┌─────────────────────┐

│ PAYMENT ACCEPTANCE │

│ PSP / Acquirer / │

│ designated merchant │

└──────────┬──────────┘

│

▼

┌─────────────────────┐

│ COLLECTING ENTITY │

└──────────┬──────────┘

│

$100 transaction

│

┌────────────┴────────────┐

│ │

▼ ▼

┌─────────────────┐ ┌─────────────────┐

│ PLATFORM REVENUE│ │ SELLER │

│ / COMMISSION │ │ ENTITLEMENT │

└─────────────────┘ └────────┬────────┘

│

│ payout

▼

┌──────────────────┐

│ SELLER PAYOUT │

│ DESTINATION │

└──────────────────┘

Overlay seven questions across the diagram:

•Who is the seller?

At the Seller node.

•Who is merchant for payment acceptance?

At Payment Acceptance.

•Who receives or controls funds?

At Collecting Entity.

•Who determines seller entitlement?

At Platform Ledger.

•Who onboards and monitors the seller?

Between Platform and Seller.

•Who refunds and bears disputes?

Draw a reverse arrow from Buyer back through the payment structure.

•Who owns payout risk?

Between Seller Entitlement and Payout Destination.

Then add geography underneath every relevant participant:

Buyer country | Seller country | Platform entity | Acquirer country | Payout country

Caption

Marketplace compliance begins where commercial roles and money movement meet.

Recommended filename

marketplace-compliance-funds-flow-map.svg

Recommended image alt text

Marketplace payment compliance funds-flow map showing buyer payment, collecting entity, seller entitlement, platform commission, seller payout, refund and dispute responsibilities

Additional visual assets

The funds-flow diagram should be the main asset, but three supporting graphics would improve comprehension.

Marketplace vs. standard merchant

Two-column comparison showing:

Standard ecommerce merchant

Marketplace

Merchant sells

Third-party seller may sell

Merchant receives economic value

Seller has an entitlement

One merchant underwriting profile

Platform + seller population

Merchant fulfills

Third party may fulfill

Merchant refunds

Allocation must be defined

Merchant receives settlement

Seller payout follows collection

Footer:

Adding a seller changes the payment architecture—not just the catalog.

Collection vs. payout

A deliberately simple visual:

COLLECTION

Buyer → merchant/payment structure

versus

PAYOUT

Platform → approved seller destination

Footer:

One checkout can create two separate payment-control problems.

“Who owns the $100?” responsibility board

Show $100 in the middle surrounded by:

Seller

Who earned the sale?

Platform

What commission is earned?

PSP/Acquirer

Who accepts and settles?

Buyer

Who owes the refund?

Payout provider

Who sends seller proceeds?

This would work especially well for executive/social promotion.

D. SEO and editorial package

Payment Compliance for Marketplaces: Funds Flow & Seller Underwriting

H1

Payment Compliance for Marketplaces: Why Multi-Party Funds Flow Changes Merchant Underwriting

Meta description

Learn how marketplace payment compliance changes when buyers, sellers, platforms, PSPs and payout providers share a payment flow—and what underwriters need before launch.

URL slug

/payment-compliance-for-marketplaces/

payment compliance for marketplaces

Secondary keywords

•marketplace payment compliance

•marketplace merchant onboarding

•marketplace payment processing compliance

•platform payment compliance

•seller onboarding payments

•marketplace underwriting

•marketplace funds flow compliance

Related entities and concepts

•marketplace

•seller

•buyer

•payment service provider

•acquirer

•payment facilitator

•platform merchant

•merchant of record

•seller payout

•third-party seller

•seller KYB

•funds flow

•chargebacks

•refunds

•merchant underwriting

•money transmission

•payment-services regulation

Article excerpt

Marketplace payment compliance starts with one deceptively simple question: who owns each obligation when a buyer pays a third-party seller through a platform? Map collection, seller entitlement, payouts, refunds, disputes, and seller onboarding before treating the marketplace as payment-ready.

Editorial recommendations

The article's strongest proposition should become a reusable line throughout the cluster:

A marketplace is a network of commercial obligations attached to a payment—not merely an online store with more sellers.

I would also make “Who owns the $100?” a designed callout directly after the introduction. It gives executives and product teams an immediate mental model without dumbing the article down.

A second callout should distinguish:

Seller KYB answers who the seller is. Marketplace underwriting also asks what the seller does, what it sells, where it receives funds, and whether that activity remains consistent over time.

Another editorial improvement would be to add a compact responsibility matrix directly beneath the funds-flow diagram:

Obligation

Platform

Seller

PSP/acquirer

Must be explicitly resolved?

Customer contracting

?

?

✓

Payment acceptance

?

?

✓

Seller onboarding

?

?

✓

Product-category control

?

?

✓

Refund

?

?

?

✓

Dispute exposure

?

?

?

✓

Seller payout

?

?

✓

Do not pre-fill it with universal answers. The question marks are the point: the merchant should populate it for its actual model.

Suggested internal links

KYC and KYB

Anchor: seller identity and business verification

High-Risk Merchant Classification

Anchor: how seller mix can affect merchant risk classification

How Geographic Expansion Triggers Re-Underwriting

Anchor: marketplace expansion and re-underwriting

Marketplace Fraud

Anchor: marketplace transaction fraud

International Payouts

Anchor: seller payout infrastructure

The cluster relationship should be:

KYC/KYB establishes who the participant is

→ Payment Compliance for Marketplaces establishes everyone's role in commerce and funds flow

→ Marketplace Fraud monitors abusive transactions

→ International Payouts explains the outbound money movement

→ Geographic Re-Underwriting explains what changes when that model crosses borders

Structured data

Use:

•Article or BlogPosting

•BreadcrumbList

Also include a genuine Last reviewed date because network standards and jurisdiction-specific payment-services rules can change.

I would not create FAQ content merely for schema. If an FAQ is added editorially, useful questions would include: Do marketplaces need to verify sellers? Is a marketplace the Merchant of Record? Can a marketplace receive customer funds and pay sellers? Who is responsible for marketplace chargebacks? What is the difference between collecting a payment and paying a seller?

E. Source and verification plan

Regulatory claims requiring publication review

UK payment-services perimeter: The FCA currently states that online marketplaces receiving customer money before passing it to sellers may be providing payment services, subject to the exact activity and exclusions such as the commercial-agent exclusion. This should be rechecked immediately before publication.

U.S. federal money-transmission analysis: FinCEN rulings make clear that money-transmitter status is fact-specific and that defined payment-processing or integral-transaction exclusions can apply. These rulings should not be presented as a marketplace-wide exemption, and state money-transmitter laws require separate analysis where relevant.

Card-network/acquirer checks

Mastercard's 2 June 2026 Mastercard Rules currently contain dedicated Platform Merchant provisions, including third-party seller information collection/verification, contracts, monitoring, and dispute responsibilities. These are unusually useful evidence that a marketplace can receive materially different acquiring treatment from a standard merchant.

Visa's current public risk materials distinguish marketplaces and payment facilitators from ordinary merchants, and Visa's acceptance-risk standards assign specific marketplace obligations within covered Visa marketplace models.

Visa's Merchant Screening Service also identifies Marketplaces, Payment Facilitators, Sponsored Merchants, and other third-party agents as specific categories used in acquirer due diligence.

Important publication note

Network terminology should not be generalized across schemes. Mastercard “Platform Merchant,” Visa “Marketplace,” payment facilitator, sponsored merchant, and a merchant's commercial use of “marketplace” may describe different formal models.

Country-specific checks

Before publication, any jurisdiction named as an example should be checked for:

•payment-services licensing/perimeter;

•money-transmission rules;

•commercial-agent or payment-processing exclusions;

•seller verification requirements;

•payout-provider requirements;

•sanctions obligations;

•acquiring-location rules.

The current article deliberately avoids creating a global “marketplace licensing checklist” because the regulatory result depends heavily on the exact funds flow.

Industry-specific checks

If the final version includes marketplace examples involving regulated or restricted seller categories, verify those categories separately. Do not infer that a category is prohibited merely because it receives enhanced network or acquirer review.

•marketplace payment acceptance;

•seller/submerchant onboarding;

•seller KYB/KYC;

•split payments;

•seller ledgering;

•marketplace payouts;

•cross-border payouts;

•reserve/negative-balance management;

•marketplace merchant-of-record structures;

•marketplace card-network registration;

•seller-category monitoring;

•multi-country marketplace acquiring.

Do not infer any of these from general global-payment capabilities.

Recommended authoritative sources

Priority sources for future refreshes should be:

•Relevant national payment regulator or legislation.

•Current Visa Rules and Visa Acceptance Risk Standards.

•Current Mastercard Rules.

•FinCEN and relevant U.S. state regulators where U.S. money movement is discussed.

•FCA or applicable EEA/national authorities for European payment-service perimeter questions.

•The marketplace's own PSP/acquirer contract and program documentation for provider-specific obligations.

F. Human review recommendation

Recommended author profile: Senior B2B payments strategist or marketplace-payments specialist with direct familiarity with acquiring, platform payments, seller onboarding, and multi-party settlement.

Compliance reviewer: Payments compliance or merchant-underwriting lead who can distinguish regulatory requirements from acquirer/network/provider policy.

Domain reviewer: Marketplace payments/product operator familiar with seller lifecycle, ledgering, refunds, negative balances, and payout operations.

Legal/regulatory reviewer: Payments counsel should review any statement about whether receipt/control of seller funds constitutes regulated payment services or money transmission in a particular jurisdiction.

Card-network reviewer: Where the published version relies materially on Visa or Mastercard marketplace terminology, someone familiar with current acquiring/network rules should verify that the described marketplace model actually matches the relevant network definition.

Recommended freshness treatment: Display Last reviewed: August 2026, and re-review when the payment model, marketplace seller population, supported countries, acquiring structure, or network rules materially change.