MoR vs. PayFac vs. Marketplace Model for Platform Teams

Three labels describe different parts of a payment business#

Merchant of Record, payment facilitator and marketplace are not three mutually exclusive business models. Merchant of Record describes responsibility for a transaction. A payment facilitator helps sponsored merchants accept payments through an acquirer. A marketplace connects buyers and sellers; some card networks also define a specific marketplace acceptance program. A marketplace business can use a PayFac or sell through an outsourced MoR service.

For a platform choosing its payment structure, begin with the actual sale: who contracts with the buyer, whose transaction is processed, who receives settlement and who handles a refund? Then compare providers that support that arrangement. A multi-seller checkout or fast onboarding promise does not answer all four questions.

At a glance: roles, customer experience and responsibilities#

These distinctions matter when product describes a marketplace, sales calls the provider a MoR and engineering implements a platform-owned charge. Those statements may describe different layers of the same setup—or incompatible assumptions. Resolve the difference before taking customer money.

Merchant of Record: transaction responsibility and outsourced resale#

Stripe’s Merchant of Record documentation illustrates how configuration matters. With direct charges, the connected account is the MoR. With indirect charges using on_behalf_of, the connected account is the MoR but the platform remains responsible for negative balances. Without that parameter, indirect charges make the platform the MoR. This is Stripe-specific guidance, not a universal rule for every provider.

The lesson is that the MoR’s identity does not, by itself, allocate every possible financial loss between the parties. Make the merchant identifiable through customer-facing information and ensure the charge configuration matches the agreed arrangement. A logo or payment descriptor is evidence to check, not a substitute for the underlying agreement.

An outsourced reseller MoR service adds a commercial arrangement. For example, Paddle explains its VAT and sales-tax role through acting as the reseller and seller on record. Its tax responsibilities concern covered sales through that service. This does not transfer every tax obligation of the product company, such as its own income or employment taxes.

If you sell software through such a service, ask which products, buyer countries, currencies and subscription changes it supports. Establish the customer’s contracting party, refund process, renewal treatment and calculation of the proceeds remitted to you. The service may simplify a covered transaction lifecycle while leaving product delivery, account support and other obligations with your business.

PayFac: merchant acceptance through an acquirer#

Visa’s acceptance-entity guide, dated February 2024, defines a PayFac by functions it performs for an acquirer: signing acceptance agreements with sponsored merchants or receiving settlement on their behalf. Either function can qualify; a PayFac does not have to perform both. Avoid treating one pooled settlement path as compulsory in every arrangement.

The sponsored merchant remains the merchant selling to the customer. Payment facilitation does not automatically turn the PayFac into a reseller responsible for the merchant’s product taxes. The guide includes payment-acceptance infrastructure such as point-of-sale systems, so PayFac is not inherently an online-only model.

For a platform using a PayFac service, the practical questions are who collects merchant information, approves onboarding, monitors activity, supports disputes and funds shortfalls. A provider may perform much of the operational work. Check what your platform must supply, which decisions the provider retains and how reserves or negative balances affect payouts.

Becoming a registered PayFac is also different from integrating a provider’s managed platform-payment product. Compare the actual acquirer and provider agreements instead of assuming “PayFac-as-a-Service” guarantees either registration status or complete risk transfer. Network obligations and any applicable local licensing requirements need their own assessment.

Marketplace: distinguish the business from the network program#

A business marketplace may connect several sellers in one checkout, arrange bookings or facilitate offline purchases. That commercial description does not identify the legal seller or its payment-acceptance classification. The platform might process seller transactions through a provider, operate a resale arrangement or qualify for a formal network program.

Visa’s public rules effective April 18, 2026, section 5.3.4, describe a branded electronic website or app that handles sales and refunds, receives settlement for retailers and meets specific dispute obligations. Registration and contracts are part of qualification; using the word marketplace is insufficient.

In that formal program, the Marketplace has financial responsibility for disputes and retailer acts or omissions under its agreement. Seller recourse does not remove those network-facing duties, and asking cardholders to waive their rights cannot transfer that liability. Identify the operator and retailer agreements alongside the customer’s purchase terms.

Visa’s 2024 guide describes customers buying from the seller through the Marketplace. Do not infer that a formal network classification makes the platform the product’s reseller in every commercial or tax context. Separate the buyer’s seller from the payment program’s operational and financial responsibilities.

Compare the work your team and provider will perform#

Do not rank the models by generic “fastest,” “cheapest” or “most control” claims. Compare the particular providers, supported countries and products, expected transaction pattern and operating work. A low payment rate can be outweighed by reserve requirements or unresolved reconciliation, while a broader reseller service can have limits that matter to your product.

For a realistic quote, give each provider the same example: buyer and seller countries, currencies, average order, seller count, refund pattern and subscription needs. Separate transaction fees from onboarding, recurring service, FX, dispute and payout charges. Ask how deductions and reserve releases appear in reports; neither headline pricing nor a model name supplies a total cost.

Worked example: two sellers, one order and a refund#

Suppose a marketplace customer pays $160: $100 for Seller A and $60 for Seller B. For this illustration only, the platform charges a 10% commission and allocates hypothetical processing costs of $5 to A and $3 to B. Tax is excluded to keep the arithmetic visible; an actual taxable order needs its own tax treatment. These are assumptions, not provider rates or recommended fees.

The initial allocation balances: $136 payable to sellers + $16 platform commission + $8 processing costs = $160. Record the order, each seller’s item, charge reference and each allocation. A single bank settlement cannot replace those records. This allocation is a bookkeeping example, not a requirement that every provider route the gross money through the platform’s bank account.

Now refund B’s $60 item before either seller payout. Assume the processor retains B’s $3 fee, the platform returns its $6 commission and the platform bears that $3 processing loss. The refund is funded from B’s $51 pending payable, $6 commission reversal and $3 platform expense. These are explicit hypothetical contract and fee assumptions; use the real policy for a live purchase.

After the refund, B receives no payout and the customer receives $60. A still receives $85. The platform retains $7 net: A’s $10 commission less B’s $3 refund-related processing expense. The processor retains $8. The check is $60 refund + $85 A payout + $7 platform net + $8 processing costs = $160.

If B had already been paid, pending funds would not be available for that refund. Establish whether the provider reverses a transfer, uses a reserve or requires recovery from the seller, and which party supplies the money meanwhile. Do not assume refunding a customer automatically recovers a completed seller payout. Track the refund and any recovery as separate events with their original references.

For a reseller MoR service, the same product sale may instead create contractual proceeds payable to the product company after service deductions and adjustments. Do not copy the marketplace commission ledger into that arrangement without adapting it. The entity’s revenue presentation also needs an accounting assessment; a gross customer charge is not automatically your company’s gross revenue.

Evidence each function needs before launch#

Keep the evidence specific to the service you will use. For example, a platform-owned charge and a seller-owned charge can have different responsibility even within one provider. Show engineering the agreed flow and finance the corresponding reports. Have legal confirm that those records match the contracting parties and applicable acceptance arrangement.

For planning payout and reserve timing, see Cash Flow Forecasting for Marketplace Operators. A cash forecast depends on the underlying settlement and adjustment records; it does not change the payment liability.

When to choose a different arrangement#

An outsourced reseller MoR can fit a supported digital-product company that wants the provider’s covered sale, transaction-tax and payment lifecycle. A platform that wants its independent sellers to remain the merchants may instead need a PayFac-backed acceptance product. A marketplace operator must also decide whether a formal network program applies, rather than treating its commercial label as approval.

A multi-seller cart is not sufficient reason to choose any one of these. Confirm that the proposed service supports the required sellers, allocations, receipts, refunds and disputes. Some configurations split one payment across accounts; others use separate charges or a reseller purchase. The customer experience and obligations must match the chosen implementation.

Revisit the arrangement when the actual business changes: new seller types or countries, subscriptions, in-person acceptance, growing dispute exposure or reports that no longer support your ledger. Diagnose the particular limitation before migrating. Adding an in-person terminal requires an approved acceptance flow; an online Marketplace approval should not be assumed to cover it.

Migrate contracts, payment flows and records together#

Before cutover, decide who sells new purchases, who handles existing subscriptions and who remains responsible for old refunds and disputes. Saved payment credentials and subscriptions are not automatically portable. Confirm provider requirements, any necessary customer agreement or consent and the intended renewal flow before using the new service.

Comparing old and new reports can expose missing references without charging customers twice. Retain a mapping between historical orders and their original provider. Do not close the old account merely because the new checkout works; outstanding obligations may continue after new sales stop.

Choose a structure you can explain from purchase to refund#

Approve the arrangement when the customer’s seller, payment configuration, contracts and finance records tell the same story. Assign each refund and dispute task and its funding source. Then choose a provider that supports that operating design in the countries and channels you need.