The Merchant of Record Operating Model: A Reference for Operators

Search the Visa Core Rules and Visa Product and Service Rules for the phrase every merchant-of-record vendor uses to describe itself, and you find nothing. Same in the Visa Merchant Data Standards Manual, the Mastercard Rules, and the Mastercard Transaction Processing Rules. Across those four documents — the 18 April 2026 Visa edition, the April 2026 data standards manual, the 2 June 2026 Mastercard Rules and the 10 June 2025 Transaction Processing Rules — merchant of record and seller of record return no occurrences.

That is not a gotcha; it is the operating model. The schemes classify by conduct, not by what an arrangement calls itself, and the classification carries obligations no label can shift. The second finding is sharper: the most detailed MoR agreement of the four examined does not absorb chargeback cost. It entitles the provider to recover the whole amount from the supplier, plus expenses, plus a per-event fee, and gives it a set-off right to take them.

Direct answer

Merchant of record is a commercial label, not a card-scheme role or a statutory status. It describes who owns the sale contract with the buyer — and that description still has to map onto a classification the scheme decides by conduct.

Visa's test does not apply to everyone. It applies to an entity that deposits a transaction, receives settlement from, and contracts with an acquirer or a payment facilitator. Such an entity is a Merchant or Sponsored Merchant only if it sells the goods or services to the cardholder, uses its name primarily to identify its outlet, and provides recourse in a dispute. Fail any of the three and it is a Digital Wallet Operator, a Marketplace, a Payment Facilitator, or a Ramp Provider instead — and Visa reserves the right to make that call. Where the entity falls into one of the four non-merchant classifications, the rules make it financially liable for disputes; for a plain Merchant or Sponsored Merchant the rulebook does not state that liability in the same terms, and scheme-facing exposure sits with the acquirer. The bar on pushing liability onto cardholders, by contrast, reaches all of them. Whether it bears the cost is a separate question answered by a private contract, and the published contracts disagree. Read yours.

The term is absent from the rulebooks examined

State the finding precisely. It is an absence from the rulebooks and guidance examined, not a claim that no regulator or tax authority anywhere uses the phrase — several revenue authorities use closely related deemed-supplier concepts — nor that the arrangement is improper. The point is narrower: you cannot look up your obligations under the label. You have to find the classification it lands in.

What the schemes actually test

Visa section 5.3.2.2 is the load-bearing rule:

An entity that deposits a Transaction, receives Settlement from, and contracts with an Acquirer or a Payment Facilitator is classified as a Merchant or Sponsored Merchant if all of the following apply:

Three conditions then follow, all of which must hold:

• "The entity is selling the goods or services to the Cardholder."
• "The entity uses its name primarily to identify its Merchant Outlet to the Cardholder."
• "The entity provides recourse to the Cardholder in the event of a dispute."

Miss one and the rule sends you elsewhere: a Digital Wallet Operator, Marketplace, Payment Facilitator, or Ramp Provider. Visa keeps the last word — it "reserves the right to determine whether an entity is a Payment Facilitator, a Marketplace, a Merchant, a Sponsored Merchant, a DWO, or a Ramp Provider and may use additional criteria" — and names some: the name on the transaction receipt, and the entity that "Owns or takes possession of the goods or services", "Books the sale as revenue", and "Provides customer service and handles returns".

Booking the sale as revenue and handling returns are exactly what an MoR provider says it does, so the label adds nothing the rule was not already looking at. An MoR arrangement is a set of conduct choices that lands in one of Visa's classifications, and Visa decides which.

Resist drawing one four-box diagram and labelling it the card networks. The vocabularies are not shared. Mastercard defines a Sponsored Merchant as "A merchant that, pursuant to an agreement with a Payment Facilitator, is authorized to accept Cards when properly presented." and adds that "A Sponsored Merchant is also referred to as a Submerchant." — and in the 2 June 2026 Mastercard Rules edition reviewed here, marketplace does not appear as a defined term at all. A Marketplace under Visa's rules must be analysed under different Mastercard constructs, not translated one-for-one. For the neighbouring boundary — PayFac against PSP against MoR — see the PSP and PayFac operations reference.

One further point, offered as PaymentBrief analysis rather than as anything the rules say: calling a marketplace the merchant of record is a claim about a particular funds flow, not an alternative to being a Visa-classified Marketplace. A platform can be both for the same sales. The classification does not go away because the deck uses a different noun.

What the cardholder sees

The receipt rules are where the model becomes visible to the person who can file a dispute. Visa's required receipt content includes a name element, "The name used by the Merchant to identify itself to its customers", with explicit combinations for intermediated models — for a payment facilitator transaction, the payment facilitator name and the sponsored merchant name (or an abbreviation), and "For a Transaction involving a Marketplace, the name of the Marketplace and the name of the retailer".

The clearing-record side is more permissive. The Visa Merchant Data Standards Manual provides that "The Marketplace may use the Marketplace name alone." — or it may insert the seller using the marketplace name (or an abbreviation), an asterisk, and the retailer name. The same convention applies to payment facilitator and staged digital wallet transactions.

So an unfamiliar intermediary name on a statement is a designed outcome of the model, not a symptom of fraud — which is why descriptor design belongs in dispute prevention rather than branding. Receipt and clearing name field are also different surfaces with different rules; satisfying one does not satisfy the other.

Who is financially liable, and to whom

Two layers get collapsed into one here, and separating them is the point.

Layer one — the scheme. Visa requires a Marketplace to be financially liable for disputes and to resolve them by providing either "A decision that binds both Cardholder and retailer" or "A money-back guarantee funded by the Marketplace". The marketplace agreement must further state that it "Is responsible and financially liable for each Transaction processed on behalf of a retailer", and that it "Must not transfer or attempt to transfer, or permit the retailer to transfer or attempt to transfer, its financial liability by asking or requiring Cardholders to waive their dispute rights". The payment facilitator and digital wallet operator rule carries materially identical wording: such an entity "Must not transfer or attempt to transfer its financial liability by asking or requiring Cardholders to waive their dispute rights". The plain-Merchant case is covered by its own rule at section 5.4.2.5: "A Merchant must not require a Cardholder to waive the right to dispute a Transaction, including an Agentic Transaction, with the Issuer."

Note the limit of those prohibitions. They forbid pushing liability onto the cardholder. They say nothing about how a provider and its supplier allocate cost between themselves.

Layer two — the contract. Here the market framing breaks down, and the published agreements disagree.

Paddle is the clearest, and the opposite of the common framing. Its Master Services Agreement appoints Paddle as "your non-exclusive reseller of the Product across all territories", states that "Paddle is the reseller of the Product. This structure allows Paddle to handle all Sales Tax collection, reporting and remittance.", and removes the supplier from the buyer relationship: "as Paddle is the seller of the Product to the Buyer, you shall not issue any invoice or make any demand for payment to any Buyer in a Transaction". So far, so consistent with the pitch. Then 10.4:

If Paddle prevents a Chargeback or refunds a Buyer (including, but not limited to, as a result of a Chargeback or Pre-Chargeback Alert), Paddle is entitled to receive from you: (i) the full amount of the refund or Chargeback; (ii) any fees and expenses incurred by Paddle in processing the refund or Chargeback; and (iii) in the case of a Chargeback or Pre-Chargeback Alert, a fee of up to 20 GBP, USD or EUR, or 40 AUD or CAD depending on the Transaction Currency (if the Transaction Currency is any other currency, this will be based on the Payment Currency).

That is an entitlement to 100% of the loss, plus costs, plus a per-event fee — backed by a set-off right under which "the Supplier hereby authorises us to set-off by whatever means the whole or any part of the Supplier's liability to us under this Agreement against any funds, sums or other amounts owing to, the Supplier under this Agreement". Paddle is liable to the scheme; the supplier is liable to Paddle. Only the first is what people mean when they say an MoR takes the chargeback risk.

Lemon Squeezy points the other way, and its own document leaves the tension unresolved. Its supplier section has Lemon Squeezy "acting as your non-exclusive reseller of the Product via Lemon Squeezy Checkout across all territories supported by Lemon Squeezy" and taking "Order support and being responsible for all aspects of Sales Tax as between you, Lemon Squeezy and Buyers." Its disclaimer section then says "Customer understands and agrees that Lemon Squeezy shall bear no risk with respect to Customer's sale, products or services, including any risk associated with the security of Customer's website, credit card fraud or chargebacks". A reseller that bears no chargeback risk is an unusual construction, and whether that disclaimer reads as a warranty limitation or a cost allocation is the question to put in writing before signing. (It also calls the entity a Utah limited liability company while the terms of service published alongside it say Delaware. Build nothing load-bearing on it without confirmation.)

FastSpring's public vendor terms are silent exactly where allocation lives: no occurrence of merchant of record, seller of record or reseller, and no clause allocating sales tax, refund funding or chargeback cost. They are not silent on control of your money. Section 4.1 says "FastSpring has the right to implement a hold on your payouts as soon as we onboard your account.", reviewed periodically and released at its discretion. And the post-termination holdback is longer than it first reads: FastSpring may retain part of a vendor's balance for up to 180 days, "or for such other period of time as may be reasonably dictated by business necessity, but not to exceed one year following termination of all FastSpring Service." Model the one-year cap, not the 180 days. Paddle has an equivalent: clauses 17.2 and 17.4 let it retain supplier fees against future chargebacks and refunds, released on or before the later of six months from termination or "the expiry of the last Product subscription" — a second limb with no fixed outer date. Fees and scope otherwise sit in an unpublished Order Form.

Xsolla publishes the role and part of the allocation, not the cost split. Its publisher terms state that "Xsolla acts as the merchant of records for the Digital Content according to the Agreement" — and that Agreement is not public. Its General Terms do allocate compliance, and against the publisher: Xsolla as a MoR takes on transaction processing, tax and general compliance, but "ultimate responsibility for compliance with territorial laws and regulations remains with the Publisher". What stays unpublished is how refund and chargeback cost is divided. The same terms say why one answer is hard: "Xsolla operates as a MoR in over 200 countries and territories, each with its own set of legal, regulatory, tax, and commercial requirements." and how content is sold "may vary significantly depending on the jurisdiction".

Four providers, four published positions, one label. Read the agreement, not the category. On the premium itself, see MoR versus PSP and when to switch.

Where the risk rules point, and who they bind

The risk side resolves like the classification side, but not the way the model's marketing implies. Visa's ecosystem risk requirements are addressed to acquirers, almost without exception. What they then require acquirers to do is push a named list of duties down into the intermediary's contract — so an intermediated seller ends up carrying real, scheme-sourced obligations that arrive by contract rather than by rulebook. Reading only the rulebook and concluding you are outside the risk regime gets this backwards.

The controls are written to acquirers. The Visa Ecosystem Risk Programs Guide organises its control requirements by acquirer archetype: all acquirers, acquirers sponsoring TPAs, acquirers processing for High Integrity Risk transaction merchants, acquirers processing for ATMs, and money movement entities. One of those describes the intermediated shape precisely — acquirers sponsoring TPAs are "Acquirers who do not directly interact with Merchants but contract with a TPA." The guide states the underlying allocation plainly: "Acquirers are liable for the actions of their Merchants, TPAs, and employees." A Third-Party Agent is "An entity, not defined as a VisaNet Processor or Visa Scheme Processor, which provides payment-related services, directly or indirectly, to an Acquirer and/or its Merchants or Sponsored Merchants" — not a Visa client in its own right. The guide is also "a supplementary document to the Visa Rules", so it is not the last word where the two differ.

Where an intermediated arrangement lands. The guide's appendix on merchant types makes one substantive statement, pointing elsewhere for the rest: marketplaces and ramp providers are registered as TPAs, but otherwise behave as a merchant or sponsored merchant. Two of the classifications the conduct test can put you in are therefore registered as agents and treated as merchants at the same time. As with the rulebooks, the phrase merchant of record does not appear in this guide either; the entity is reached through what it does.

The duties do reach you — and the guide writes them. This is the part the "we take on the risk" framing obscures. Where an arrangement lands as a Marketplace, the acquirer "is liable for all acts, omissions, and other adverse conditions caused by the Marketplace and its retailers", and the guide's mandatory controls require the acquirer to ensure the marketplace agreement provides that:

• "The Marketplace enter into a contract with each retailer before it deposits Transactions on the retailer's behalf."
• The marketplace "Is responsible and financially liable for each Transaction processed on behalf of a retailer."
• The marketplace "Must not knowingly contract with a retailer whose contract to accept Transactions was terminated at the direction of Visa or a government agency."
• The agreement preserves "The Acquirer's right to prohibit individual retailers from participating in the Visa system and to immediately stop depositing Transactions for any individual retailer for good cause or upon Visa request."

Where it lands as a Payment Facilitator the shape is the same: "The PayFac is obligated to establish a contract with each Sponsored Merchant", and the PayFac must "Accept liability for all actions, neglect, Cardholder disputes, and other Cardholder-related customer service issues caused by the PayFac's Sponsored Merchants". Past a size threshold the intermediary stops being the only counterparty at all — an acquirer contracting with a payment facilitator must "establish a direct Merchant Agreement with any Sponsored Merchant that has an annual Transaction volume exceeding USD 1 million".

And the acquirer is required to check that you actually do this. Its TPA underwriting includes "Verifying the TPA's onboarding procedures for Sponsored Merchants" and "Ensuring the TPA has policies and procedures (e.g., Merchant onboarding, Merchant activity monitoring, Merchant written agreements) in place"; separately, "Acquirers must review onboarding policies and how Marketplaces conduct due diligence of their sellers."

So the honest answer to who underwrites the seller is neither "the scheme makes you do it" nor "nobody". If the conduct test lands you as a marketplace or a payment facilitator, seller-level contracting, screening against Visa-terminated counterparties, and financial liability for your sellers' transactions are mandated content of your acquirer agreement. They are not merely commercial terms you could negotiate away, and an acquirer that omits them is out of line with its own standards. What is genuinely absent is narrower than it first looks, and worth stating precisely: nothing in the guide requires an intermediary to risk-tier its sellers, and nothing requires it to hold a reserve against them.

What the model looks like to a monitoring acquirer. The guide carries two accounts of transaction laundering, and the difference matters. The mandatory prohibition your merchant agreement must carry is narrow — "Transactions that are knowingly intended to hide the true source and nature of the transaction by layering them through what appear as low risk but in fact it is prohibited goods or services as per the Visa Rules" — which requires knowing intent and prohibited goods, and does not describe a reseller of lawful software. The wider description, in the monitoring control, is "a sophisticated form of money laundering where an unknown business uses an approved Merchant's payment credentials to process card payments for undisclosed goods or services", and the guide notes it is "also known as factoring".

The reseller shape is close enough to that second description that the guide addresses it head-on, in the TPA controls: "Prohibiting a Merchant or Sponsored Merchant from submitting a transaction representing sales of goods or services fulfilled by another Merchant or Sponsored Merchant curtails the risk of transaction laundering." That is the sentence to sit with. It is not an accusation about resellers, and the operative word is undisclosed — an MoR whose model was disclosed and underwritten as what it is has been onboarded on that basis. But it explains why the monitoring lands on the model rather than around it. The acquirer's recommended controls tell it to "Regularly verify the websites of your Merchants to ensure that they are only selling the products or services they have declared", to watch for merchant-name and MCC mismatches, and to look for "transactions that do not match the nature of the underwritten Merchant" — tests a broad third-party catalogue can trip unless the acquirer already understands the arrangement. Worth knowing how much force those carry: the transaction-laundering control requirement has no mandatory controls at all, only two recommended ones, so the detection techniques are guidance rather than obligation. The operator consequence is still concrete — a provider that quietly broadens its catalogue past what its acquirer underwrote is building an exposure, and the party holding it is the provider. The signal ladder an acquirer runs against a portfolio — triggers, graduated response, and the line between suspension and offboarding — is set out in ongoing merchant monitoring and offboarding.

The prohibitions your own agreement must carry. The guide introduces them with "The Merchant agreement should outline the following prohibitions" — but places the list inside its Mandatory Controls block, so read the column, not the modal verb. The four are transaction laundering, resubmission of previously disputed charges, submission of fraudulent or unauthorised transactions, and data-security breach. Whether they then reach the sellers behind an MoR is a question about that provider's supplier contracts, which the scheme does not write.

Reserves run upward. The guide contemplates reserves in one direction only. Settlement may be withheld against "Merchant reserve funds (if applicable) accumulated to secure the Merchant's, Sponsored Merchant's, Marketplace's, PayFac's, or DWO's payment system obligations to the Acquirer" — in every case obligations owed to the acquirer, whether by the intermediary or by a seller beneath it. Where an acquirer holds them they are collateral that is "property of the Merchant, which is held and controlled by the Acquirer in a unique deposit account in the Merchant's or Sponsored Merchant's name". Nothing in the guide requires, sizes, or governs a reserve that a merchant of record holds against one of its sellers. That is a commercial term in the provider's agreement — item 4 in the checklist below — and it should not be read as a scheme-mandated protection. The acquirer-side mechanics, where the scheme does speak — underwriting a legal entity cold, attaching reserves as a condition of approval, and what a for-cause termination puts on file — are covered in MID lifecycle operations.

What this does not establish. The guide does allocate economic loss between an acquirer and an intermediary — that is what the liability provisions above do — but it is silent on allocation between the intermediary and its own sellers, which remains the contract question set out earlier. It does not describe the MoR model, and every finding here comes from placing the model inside a taxonomy built for something else. It is supplementary to the Visa Rules, which govern in a conflict. An arrangement selling high-integrity-risk goods falls under a further archetype whose controls are mandated for acquirers and their TPAs directly, which is outside this reference. And the guide carries an October 2024 date, older than the rulebook editions cited elsewhere here, so confirm the current version before relying on a control number.

Where tax law asks a different question

Tax authorities do define something close to this arrangement, but on their own tests, per instrument, and those are not the scheme tests. Singapore and the UK share a four-factor shape: the platform is treated as the supplier where it sets the terms and conditions · authorises the charge · authorises delivery · is identified as the seller in the documentation. California does not use that test at all.

• Singapore. The Goods and Services Tax Act treats an electronic marketplace operator as making the supply instead of the underlying supplier if any one of five conditions is met — the four above, plus a written agreement that the operator is chargeable: "(a) the operator authorises the consideration for the supply to be charged to the customer; (b) the operator authorises the delivery of the supply to the customer; (c) the operator sets the terms and conditions under which the supply is made; (d) the documentation provided to the customer identifies the supply as being made by the operator;". The definition of an electronic marketplace excludes "but not any medium that is solely for processing any payment for any supply". Where the operator is treated as supplying distantly taxable goods, paragraph 4(5) recharacterises the underlying supply as two — supplier to operator, operator to customer. That limb is expressly about goods; do not carry it across to services.
• United Kingdom. HMRC's digital-services guidance runs the parallel conditions from the other direction: a platform is liable for the VAT unless the parties identify the supplier contractually, the invoices identify that supplier and the service, and the platform does not "authorise the charge to the consumer", "authorise the delivery", or "set the general terms and conditions of the sale". It also carves out the pure processor: "If your only role in the supply is to provide for the processing of payments you're not regarded as a digital platform and you do not have to account for the VAT." The UK's rules for goods sold through online marketplaces are a separate instrument, under which the overseas seller "will be considered to have made a zero-rated supply of the goods to the online marketplace, known as a 'deemed supply'". Two regimes, two scopes.
• California. The CDTFA states that "a marketplace facilitator is considered the seller and retailer for each sale facilitated through its marketplace". Check the scope: the guide defines a marketplace as "A physical or electronic place where marketplace sellers sell or offer for sale tangible merchandise for delivery in this state." It is not authority for SaaS in California, and it covers one state only. None of the four factors above appears in the guide: California turns on facilitating the sale and on registration thresholds, not on who sets terms, authorises the charge or delivery, or is named in the documentation.

The answer moves with the jurisdiction and the kind of thing sold, so a provider statement that it handles tax is a starting point for scoping, not a conclusion. Depth on what is covered and what stays yours is in what your MoR handles for tax.

Money and timing

The scheme layer. Visa requires that a Marketplace "must pay or credit its retailer's account promptly after Transaction Deposit. These payments must be the same as the Transaction totals, less any Credit Transaction Receipts, applicable discounts, Disputes or other agreed fees." A promptness obligation plus a closed list of deductions. One detail is easy to get wrong: the acquirer-side sentence in the same rule permits deduction of "other agreed fees or Merchant reserve funds (if applicable)" — but that reserve wording does not appear in the marketplace-to-retailer sentence. Do not merge the two into a claim that scheme rules let a marketplace hold reserves against its retailers.

The contract layer. Payout mechanics are commercial, not scheme-set. As a single-provider illustration, not an industry norm, Paddle pays the supplier "on or before the 15th of the following month" provided the accrued fee is "above $100, €100 or £100 (or some higher amount as agreed between you and Paddle)", and applies "a foreign exchange margin of 2% for major currencies (USD / EUR / GBP), 2.5% for CZK, DKK, NOK and THB, and 3% for all other currencies". Those numbers are Paddle's, not a benchmark: no other provider examined publishes FX or payout-schedule figures in its legal terms, though FastSpring publishes other amounts, including the retention periods above. A monthly cadence and an accrual floor are what most often surprise a cash-flow model built on daily card settlement, and both are contract terms, not rules you inherit.

What this reference does not establish

• Payment-method access. No scheme-rule or provider-agreement evidence was found for the claim that an MoR reaches local payment methods you could not. None of the legal agreements examined describes method coverage; only vendor marketing does, and this site does not cite vendor marketing. Unverified.
• Data and reporting artefacts. Three of the four do commit to something: FastSpring undertakes to "provide Vendor with its data in a standard form within 30 days of termination", and Paddle and Lemon Squeezy both promise dashboard reporting of sales and amounts due. None specifies file formats, field lists, retention periods, or sample artefacts, so none of it is comparable before you sign. Ask for samples in diligence.
• FX margins as an industry norm. One provider publishes a margin schedule. One data point is not a market.
• Any general "an MoR handles your tax" claim. Each jurisdiction runs its own test on its own scope, and the agreements differ on what they promise.
• Digital River. Frequently cited here; no current legal agreement could be retrieved, so it is not discussed.
• US state sales tax generally. Only California's guide was examined, and only for tangible merchandise.

Operator checklist

Read your own agreement for these five (PaymentBrief operator guidance, not legal advice).

1. Refund funding. Who is out of pocket on a refund, and is the provider's fee refunded with it?
2. Chargeback recharge. Is the full amount passed back? Is there a per-event fee, a cap, a dispute-rate trigger?
3. Set-off. Can the provider deduct without notice and require a top-up?
4. Reserves and holdbacks. On what trigger, at what size, and against which outer date — the first number in the clause, or the one at the end of the sentence?
5. Payout timing. Cadence, accrual threshold, FX margin, transfer fee, and the fate of your balance at termination.

Silence on any of these is not an oversight to assume away. It is the term to ask about first.

Related references

• PSP and PayFac operations reference
• What your MoR handles for tax
• MoR vs PSP: when to switch
• When MoR stops making sense
• MoR migration playbook
• MID lifecycle operations
• Ongoing merchant monitoring and offboarding

Scope note

• Rulebook editions. Scheme claims come from the Visa Core Rules and Visa Product and Service Rules (18 April 2026 public edition), the Visa Merchant Data Standards Manual (April 2026), the Mastercard Rules (2 June 2026), and the Mastercard Transaction Processing Rules (10 June 2025) — two different documents carrying two different edition dates. Confirm the current edition before relying on a section number.
• Absence claims are scoped to those documents — not to every scheme document, regulator, or jurisdiction.
• Provider claims name their contract, current at the date accessed. Terms change without notice; none describes MoR providers generally.
• This is not legal or tax advice. Scheme classification is the scheme's call; deemed-supplier status is each tax authority's, on its own instrument. Confirm both with your acquirer and qualified advisers in every market you sell into.