A customer buys a pretax $100 SaaS annual subscription and pays $20 more in tax. Both setups can mark the order paid. Direct payment processing still has your company selling to the customer and carrying tax, refunds, and delivery. A merchant of record (MoR) becomes the seller the buyer faces on in-scope orders, then pays you a supplier amount after tax, fees, and contract adjustments.
That is the merchant of record vs payment processor difference that matters. A payment processor answers how authorization, capture, and settlement complete. An MoR also changes who sold the product to the buyer. Hosted versus embedded checkout, whose API you call, and which balance first held the funds cannot prove seller identity on their own.
When enterprise buyers require the contract, purchase order, invoice, and payee to name your company, a processor is usually the cleaner fit. When a standard digital product is sold self-serve into many countries and the team cannot run multi-jurisdiction indirect tax, transaction documents, and disputes as standing work, an MoR is more valuable. Those buyer requirements can point opposite ways. Split channels only if seller, documents, refunds, and renewals are stored per order.
This choice assumes the contracting entity, product, buyer markets, payment methods, and settlement account already have current evidence. A missing file is not the same as a confirmed refusal, and changing the responsibility model does not reopen a route the current evidence already closed.
Merchant of record vs payment processor: who the buyer purchases from
A payment processor is payment execution. It takes a merchant payment request to an acquirer, card network, issuer, or other payment network, then returns an authorization and completes capture, refunds, and settlement. A modern payment service provider (PSP) can also supply checkout, risk tools, subscription billing, tax calculation, and reports. Those features do not, by themselves, make the PSP the legal seller. Adyen’s PSP explainer keeps gateway, processing, and acquiring inside payment services; in an ordinary PSP setup the merchant remains the legal seller. Adyen: Payment service provider(opens in a new tab)
Merchant of record is a commercial role on a sale. On in-scope orders the MoR contracts with the buyer as seller or authorized reseller, then pays the product supplier a net amount under a supplier agreement. Paddle’s supplier agreement(opens in a new tab) is a reseller appointment. The buyer terms(opens in a new tab) state that the buyer purchases the product from Paddle, and the supplier makes the product available.
So “Stripe is a processor, Paddle is an MoR” can describe one product. It cannot classify the whole brand. Ordinary Stripe Payments usually leave the merchant as seller. Stripe Managed Payments is a different service: on covered transactions the customer sees Link as merchant of record, and Stripe documents the indirect tax, transaction support, and dispute work that go with that role. Stripe on merchant of record(opens in a new tab), How Managed Payments works(opens in a new tab)
Even when the contract names the MoR as seller, “the platform is responsible” is still too coarse. A refund or chargeback sits in at least five places:
| Place | Question to answer | Easy false reading |
|---|---|---|
| Contract identity | Who contracted with the buyer, and who appears on the applicable terms and sale documents | “Whose checkout page is this?” |
| Operations | Who calculates tax, issues the refund, receives the dispute, and submits evidence | “The platform will handle it” |
| Decision rights | Who can decline a sale, grant a refund, restrict a product, or freeze an account | “I still have full control” |
| Economic result | Who finally carries refunds, chargeback fees, fines, reserves, and a negative balance | “The platform takes the liability” |
| Data and evidence | Who can access, use, export, migrate, and keep records | “The customer data is mine” |
Seller identity answers only the first row. Whether the other four move, and how far, has to be read from the current product, the target transaction, and the signed agreement.
The same subscription creates two contract and money paths
On a direct processor path, the product sale is between the buyer and the SaaS company. The SaaS company separately signs a payment-services agreement so the processor can capture funds through the financial network and move settleable money into a merchant balance or bank account. The processor handling funds does not mean it sold the product. Transaction tax, refund decisions, and fulfillment still start from the SaaS company’s sale.
An MoR path adds a reseller layer. The buyer pays under the MoR’s buyer terms. The SaaS company grants sale rights and delivers the product under a supplier agreement. The MoR collects the buyer payment, deducts tax, service fees, and allowed adjustments, then pays a supplier amount. Paddle currently splits that work: Paddle handles resale and order matters; the supplier keeps the product available, delivers it, and provides technical support. Paddle agreement clauses 2, 3, and 6(opens in a new tab)
Which balance first holds the money cannot prove who sold. A processor may hold merchant funds for a time. An MoR still needs an acquirer or processor to run the payment. The reliable test is a set of records on the same order that agree: the contracting entity in the buyer terms, the seller disclosure at checkout, the invoice or receipt header, the card statement name, and the supplier settlement file. One logo or field on a screen does not replace the signed agreement.
Transaction tax follows the in-scope seller
Cross-border SaaS “tax handling” is not a calculator switch. It includes obligation, registration, calculation, filing and remittance, sale documents, and the adjustment after a refund. A checkout that shows the right amount has only finished calculation.
On a direct processor path the SaaS company is usually still the seller. A tax product can calculate VAT, GST, or sales tax from product class and buyer location. The operating company still has to decide where an obligation arises, then register, file, and remit. Stripe Tax lists registration, calculation, and filing as separate steps; tax collected for registered locations is still the merchant’s to file and remit. Stripe Tax: File and remit(opens in a new tab)
An MoR can handle indirect tax on covered transactions because it is the seller or related statutory actor on those orders. Countries, products, or channels outside that cover do not disappear. Product description, tax classification, and source data from the supplier still have to be accurate. Stripe Managed Payments says uncovered countries remain the merchant’s indirect-tax job. Paddle’s agreement requires correct product, classification, and price data, and keeps the right to recover losses from bad information. Stripe Managed Payments tax boundary(opens in a new tab), Paddle supplier tax terms(opens in a new tab)
Keep two ledgers. The first is the buyer sale: who the seller is, and which indirect tax that seller registers, collects, and files. The second is the SaaS company: after a processor payout or an MoR supplier amount, how income is recognized and how its own tax is handled. Changing payment providers can move part of the first ledger. It does not erase the second.
Invoice seller and card statement name change what the buyer sees
After payment the buyer meets at least three visible records: the invoice or receipt that names the seller, the charge name on the card or payment account, and a credit note or refund notice if money comes back. The SaaS company receives a different set: provider balances, settlement reports, remittance advice, or reverse invoices between the MoR and the supplier. The first set proves the buyer sale. The second set explains the supplier amount. An admin order screen replaces neither.
| Visible record | Direct processor | In-scope MoR sale | Confirm before you choose |
|---|---|---|---|
| Buyer terms | Buyer contracts with the SaaS company | Buyer contracts with the MoR or authorized reseller | Legal entity, product, and country sit inside the agreement |
| Invoice, receipt, credit note | Issued in the merchant’s name, by the merchant or its tools | Usually issued by the MoR in its seller role | Seller name, tax IDs, buyer tax ID, currency, PO, local format |
| Card statement | Uses the merchant account’s statement descriptor | Often prefixed with the MoR or a consumer brand | Buyers can recognize it; support copy says so in advance |
| Supplier settlement files | Processor balance and payout reports | MoR supplier amount, statement, reverse invoice, or remittance advice | Accounting can rebuild sales, tax, fees, and adjustments from the net |
On Stripe Invoicing where the merchant is the seller, invoices can show the merchant’s brand and business details. Accuracy and local format still sit with the merchant. The card statement descriptor should also reflect the doing-business-as name so the buyer can recognize the charge. Stripe invoice customization(opens in a new tab), statement descriptor rules(opens in a new tab)
MoR sale documents have to show that seller identity. Paddle currently prints card statements as PADDLE.NET* COMPANYNAM. Stripe Managed Payments prints LINK.COM* [merchant descriptor]. Part of the product or merchant name can remain. The Paddle or Link mark still appears. Paddle statement description(opens in a new tab), Stripe Managed Payments statement descriptor(opens in a new tab)
Consumers who do not recognize the statement name often dispute with the bank before they write to support. Enterprise procurement is a different friction: contract party, vendor file, purchase order, invoice seller, and payee may have to match. A provider that “supports invoices” does not mean the buyer’s purchasing rules accept an MoR. If annual B2B is the main revenue, walk a real procurement contact through quote, vendor onboarding, PO, invoice, payment, and credit notes before making that the default channel. Paddle can issue sales-assisted invoices and collect payment. Whether purchasing will pass still depends on the buyer’s rules and contract. Paddle Invoices(opens in a new tab)
An MoR handling refunds and chargebacks does not mean the supplier takes no loss
“The platform handles refunds and chargebacks” is the easiest misread. Who the buyer asks, who decides the refund, who sends the money back, who evidences the bank, and whose balance is debited can belong to different parties.
On ordinary Stripe Payments, a card dispute notifies the merchant and opens an evidence path. The disputed amount and fee leave the merchant balance. The cardholder’s bank decides the outcome. The merchant can accept the dispute or submit evidence before the deadline. Stripe: How disputes work(opens in a new tab). Stripe running the dispute process does not mean Stripe absorbs the loss.
When Paddle is MoR, the dispute is raised against Paddle, and Paddle’s system collects and submits evidence. The disputed amount and processing fee are still deducted from the supplier balance first. A win returns the disputed amount. The fee is not refunded. Paddle: Understanding Chargebacks(opens in a new tab). The supplier agreement also lets Paddle refund on its own in stated cases, set off balances, require a shortfall to be funded, or hold money against future refunds and chargebacks. Paddle Master Services Agreement(opens in a new tab)
Stripe Managed Payments gives transaction support to Link. Stripe decides whether to counter a dispute, and may refund directly in some cases within 60 days of the original sale. A received dispute still incurs a fee. Some jurisdictions still require the original sales tax after a refund, and that tax amount reduces the merchant account balance. Stripe Managed Payments: refunds and disputes(opens in a new tab). A product labeled Merchant of Record still has to be checked for refund tax, dispute fees, and balance adjustments.
An MoR can take the outward sale role, day-to-day operations, and some compliance work. The supplier is not therefore free of cash loss. In the contract, handle, manage, defend, and liable are not the same promise. Read them with refund amounts, fees, reserves, set-off, negative balance, and post-termination duties. The next settlement statement is what moves cash, not a product page that says chargebacks are handled.
Risk, PCI, and product delivery do not leave with the seller role
Hosted Checkout and hosted payment fields can shrink the merchant’s contact with raw card data. “No plaintext PAN touched the server” is not the same as no payment-security duty. PCI Security Standards Council is explicit: even when payment processing is fully outsourced, the merchant still has to confirm the provider’s compliance scope, allocate duties in a written agreement, and keep managing that third-party relationship. PCI SSC: outsourcing payment processing(opens in a new tab)
Paddle’s current agreement lets it review the supplier, the product, and the site, and lets it restrict sales, delay payout, refund, or stop selling under risk conditions. The supplier remains responsible for product description, tax classification, pricing, delivery information, intellectual property, availability, and technical support. Paddle Master Services Agreement(opens in a new tab). Other MoRs may split risk control and supplier duties differently. Only the signed agreement answers that.
Whoever the seller is, the SaaS company still decides what the user can use today. The business system should keep users, the sellable catalog, orders, subscriptions, payment attempts, and entitlement state, and map external customer, price, transaction, and subscription IDs. Provider events are external payment or contract facts. They cannot replace local orders and entitlements. Otherwise one channel switch, late event, or dispute refund can collapse “once paid” and “still entitled” into the same flag.
Customer data is not answered by who owns it
Exporting a customer-email CSV only proves that export exists. It does not prove card credentials can move, that the original debit mandate still works, or that fulfillment data may be used for marketing. Whether customer data is “in your hands” is at least five separate abilities.
| Data ability | Fact to confirm | Effect on migration |
|---|---|---|
| Access | Which customer, order, invoice, tax, and dispute fields the API, reports, and dashboard return | Missing fields block support, reconciliation, or a new-system map |
| Use | Who is controller versus processor, and which purposes cover fulfillment, support, risk, and marketing | Seeing a field is not a license to copy it or market with it |
| Export | Whether ordinary customer and transaction data can be bulk-exported in a stable format, and how long access lasts after termination | Sets history lookup and local archive |
| Credential transfer | Whether card tokens, bank mandates, or wallet credentials can move to a new PCI-compliant vault | Sets whether customers must re-bind a card |
| Renewal mandate | Whether the original debit mandate and merchant-initiated relationship can continue with a new seller or processor | Sets whether live subscriptions can renew without a new authorization |
Paddle’s current data-sharing addendum treats Paddle and the supplier as independent controllers, and lists shared data such as name, address, email, purchase history, and dashboard transaction analytics. Each party is responsible for its own processing purposes. Paddle Data Sharing Addendum(opens in a new tab). “Customers belong to the MoR” and “customers always belong to the supplier” both undersell the actual rights.
When the conditions are met, Stripe can transfer customer card data to a new PCI DSS Level 1 processor. Payment credentials stored with Link are outside that transfer. Stripe: Request a payment data export(opens in a new tab). One account can hold transferable card data and Link credentials that cannot move across processors. Migration ability belongs to the credential type. “Stripe supports export” does not mean every live renewal can leave.
Local customer IDs, product entitlements, contract versions, and support records should stay in the SaaS system. Provider-side customers, subscriptions, invoices, and transactions are external objects, joined through stable IDs. Email is a poor unique key: it changes, and it can map to duplicate customers. That join is what keeps one business identity through deletion, email changes, or a channel move.
Migration cost starts with the first automatic renewal
One-off charges are easier to switch: new orders enter the new system, old orders stay on the old system for refunds and disputes. Automatic renewals are different. Each live subscription carries the old seller, payment credential, debit mandate, remote state, next charge time, and historical tax documents. Those objects do not move because you rotated an API key.
| Object | Typical move | Why it cannot be copied as-is |
|---|---|---|
| Products, prices, discounts | Rebuild on the new provider and store old/new ID maps | Fields, tax class, billing period, and version semantics differ |
| Customers, addresses, tax IDs | Export, clean, import, and join to the local customer ID | Duplicates, privacy purpose, and required fields differ |
| Payment credentials | Controlled transfer into a new PCI-compliant vault, or a fresh customer authorization | Merchants should not touch plaintext card data; wallets and some tokens cannot move |
| Live subscriptions | Rebuild next charge, period, quantity, trial, cancel, and discount state in batches | Remote subscription IDs and state machines are provider-owned |
| Invoices, tax, refunds, disputes | Keep them on the old system until tail events close | They belong to the original sale and seller; they cannot be rewritten as new-channel history |
| Local orders and entitlements | Keep local truth; update provider ID maps and renewal source | What the user bought and can use should not change with a channel ID |
After security checks, Paddle can move customer payment details to a new PCI-compliant vault; subscriber data is exported by the supplier. Stripe card export also needs the old and new processors to complete an encrypted transfer. Paddle Subscription Migration Process(opens in a new tab). Credential transfer solves only part of the renewal chain. Product prices, subscription state, webhooks, local maps, and historical reconciliation still have to be rebuilt or continued.
Before signing, confirm which objects and formats can leave, processing time, receiver qualifications, payment methods that cannot transfer, how long access lasts after termination, and who keeps handling refunds and disputes on old sales. “Supports export” without those details has almost no decision value for live subscriptions. Asking at termination is usually too late to avoid a re-authorization.
Recalculate operating net on a $100 annual subscription
The pretax subscription price is $100. The buyer pays $20 more in indirect tax. Assume the processor charges $3.60 on this payment, and the MoR deducts $5.50 from pretax sales. FX, refunds, chargebacks, reserves, cross-border payout fees, and the supplier’s own tax are left out. The rates only show the method. They are not a quote.
| Money location | Direct processor | In-scope MoR sale |
|---|---|---|
| Buyer pays | $120.00 | $120.00 |
| Receiver of the buyer sale | SaaS company, collected through the processor | MoR |
| Indirect tax | SaaS company records $20.00 still to file | MoR records, files, and remits $20.00 |
| Demo service fee | $3.60 | $5.50 |
| Settleable provider balance or supplier receivable | $116.40 | $94.50 |
| Operating net after this sale’s indirect tax | $96.40 | $94.50 |
The processor path may first show a $116.40 settleable balance. $20.00 of that is still tax waiting to be remitted, so spendable operating income is $96.40. On the MoR path the MoR records and remits the buyer tax, and the supplier receivable is $94.50. That supplier income still enters the company’s own books and tax records.
Close amounts can still arrive on different calendars. Suppose the processor holds 10% of the buyer payment, $12.00; the unreserved remainder pays out on day 7, and the $12.00 releases on day 30. The MoR sets no extra reserve in this demo, but pays the supplier on day 30. A real model has to replace those numbers with the rolling reserve, payout cycle, minimum payout, and bank posting time in the account agreement.
| Time or state | Direct processor | In-scope MoR sale |
|---|---|---|
| Payment success day | Buyer pays $120.00; provider balance is $116.40 | Buyer pays $120.00; supplier receivable is $94.50 |
| Day 7 | Operating account receives $104.40; $12.00 still reserved | Supplier payout has not arrived |
| Day 30 | Reserved $12.00 releases; cumulative receipts $116.40 | Operating account receives $94.50 |
| Cumulative receipts after this sale’s indirect tax | $96.40 available to operate | $94.50 already net of this buyer tax |
A reserve is temporarily unavailable. It is not automatically a fee. A refund, chargeback, or negative balance can still be taken from it under the contract. An MoR may also set a reserve, a set-off, or a minimum payout. The $94.50 in the table becomes fully usable on day 30 only if nothing extra is held, the balance meets the payout threshold, and the bank posts on time. An annual cost model therefore has to separate “how much was deducted” from “when the cash can be used.”
Under those assumptions, direct processing’s operating net is $1.90 higher on this sale. That $1.90 does not pay for tax registration and filing, invoices, disputes, finance hours, engineering upkeep, or error cost. MoR cost is also more than $5.50: payout cycle, FX, reserves, refund and chargeback deductions, control given up at a standard checkout, and a later migration. Both options have to be run on the same transaction count, countries, currencies, refund rate, average order value, and labor cost.
Processor annual cost = payment and FX fees + tax and document operations + risk and disputes + engineering and finance hours + cash tied up + exit cost
MoR annual cost = MoR contract deductions + payout and FX + unabsorbed refunds and disputes + control cost + cash tied up + exit cost
Work the contract does not take on cannot be deleted from the cost. Booking internal hours as zero, or reading “the platform handles chargebacks” as zero loss, pushes the answer to the wrong side.
When these symptoms appear, responsibility did not fully transfer
| Observable symptom | Wrong reading | Actual boundary | Return to the main path |
|---|---|---|---|
| Every VAT amount is already calculated, and there is no filing record | “Tax is done because the tax feature is on” | Calculation, registration, filing, and remittance are different jobs | Match registered entity, filing account, remittance record, and out-of-scope sales by seller and country |
| The MoR already submitted chargeback evidence, and the next payout is still short the sale and the fee | “The MoR handled the chargeback, so the supplier lost nothing” | Operations ran at the MoR; cash loss can still be recouped by contract | Check balance adjustments, set-off, reserves, and what returns after a win |
| The buyer says they did not buy this product, or enterprise finance refuses the invoice | “The product name on checkout is enough” | Invoice seller and statement prefix may be the MoR | Name the seller and statement before purchase, in the receipt email, and on the support page; verify with a real procurement path |
| Customer and subscription CSVs exported, and the new channel cannot start the next renewal | “Exportable data means the subscription can move” | Credentials, renewal mandates, and remote state may not travel with ordinary data | Get the credential-transfer scope, run one real renewal cohort; if transfer is impossible, plan re-authorization |
paid only proves the payment request completed. It does not prove contract, tax documents, dispute, funds, and renewal have all closed. When something looks wrong, first identify which record failed to converge, then the party that owns that record. Do not let one payment status cover the whole sale.
Choose processor or MoR by which remaining work you cannot carry
An entity that cannot contract or settle, a product outside the service scope, or a buyer or payment method that is unavailable, makes a candidate “not applicable.” Those hard boundaries are eligibility evidence, not a fee comparison. If the missing piece is the current agreement, an account review result, or cover evidence for the target sale, keep the state as “needs verification.” Do not default it to available, and do not treat it as permanently unsupported.
After eligibility holds, let the buyer’s contract and invoice rules choose the seller. If enterprise buyers must contract with your company, prefer a processor. If consumer orders accept an MoR and enterprise orders require a direct contract, two sales channels are required. If the buyer does not force the seller, compare whether the team can carry multi-market tax documents and dispute operations, and whether it can give up pricing, data, funds, and exit control.
Only when both models clear the hard conditions does cost comparison start. Recompute on the same volume, countries, currencies, refund rate, and labor price, and write credential export, historical document retention, and disputes on old orders into exit cost. Public fee tables occupy one row of that model.
| Business constraint | Leans direct processor | Leans MoR | Not applicable |
|---|---|---|---|
| Buyers and markets | A few known markets, or enterprise buyers require a direct contract | Multi-country self-serve B2C, with scattered indirect tax and consumer support | Target country, product, or buyer type is outside actual cover |
| Invoices and purchasing | Own entity, tax IDs, PO, payment terms, and custom contracts cannot be replaced | Buyers accept the MoR seller and its standard or sales-assisted invoices | Buyer requirements conflict with the seller or documents the MoR can issue |
| Product and checkout | Complex billing, custom checkout, routing, and method control are core | Standard digital product; the provider’s checkout and refund rules are acceptable | Marketplace, third-party collection, or regulated activity treated as ordinary SaaS |
| Team capacity | Tax, finance, risk, support, and payments engineering each have a named owner | A small team cannot run multi-jurisdiction tax documents and disputes | A key duty has neither an internal owner nor a provider that clearly takes it |
| Funds and total cost | Volume can support modular operations, and the cash cycle is tolerable | Packed work saves more real cost than the fee gap | Reserves, payout cycle, FX, or negative balance would break cash flow |
| Data and exit | Payment credentials, routing, and customer relationship must stay under direct control | Agreed uses, standard export, and a collaborative migration are acceptable | No account of live renewals, historical documents, and post-termination disputes |
Choosing a processor keeps the operating company on the buyer contract, documents, refund policy, payment orchestration, and funds relationship, and those jobs need long-term owners. Choosing an MoR lets one seller run multi-market transaction work, and the supplier accepts that seller’s product scope, risk decisions, buyer documents, payout rhythm, data uses, and exit process.
A mixed model holds only when order constraints actually differ. Self-serve B2C sold by an MoR, and annual enterprise contracts collected by the operating company through a processor, are two named sales channels, not two payment buttons shown at random. Every order has to store seller entity, provider product, tax owner, invoice issuer, refund entry, and renewal-authorization owner. Provider support for transaction-level MoR is only the prerequisite. Local catalog, orders, entitlements, and finance also have to recognize two fact sets.
What the choice looks like for self-serve B2C, enterprise B2B, and mixed sales
Self-serve B2C across many countries
A small team sells a standard online tool on monthly self-serve subscriptions. Buyers sit in the EU, the UK, the US, and several Asia-Pacific markets. There is no dedicated tax, finance, or dispute owner. If the entity, product, and settlement account clear eligibility, and buyers accept the MoR seller name and refund path, an MoR usually fits these orders: multi-jurisdiction indirect tax, sale documents, and dispute operations can run under one seller.
That is not a license to pick any MoR. Sale countries, product class, payout currency, refund and chargeback deductions, data uses, and credential export still have to match that company’s real conditions. The first live small order should still check the buyer invoice, statement name, webhook, local entitlement, and final payout. Missing cover evidence stays “needs verification.” A hard condition the agreement rejects is “not applicable.”
Annual enterprise B2B: buyer procurement decides the seller
A UK limited company mainly signs annual enterprise contracts. Customers require vendor onboarding, a purchase order, a signed contract, 30-day terms, and documents that use the UK company’s tax details. The team already has accounting and cross-border tax support. Web checkout is not the main sales entry. Contract and document identity then matter more than self-serve tax automation. A processor, bank transfer, and an owned invoicing stack usually keep one supplier identity.
An MoR path holds only if the enterprise customer accepts the MoR as seller, the sales-assisted invoice can carry PO and tax fields, and the product terms still apply. Letting a real customer’s purchasing and finance walk the full document chain is cheaper than discovering after integration that the contract party is refused.
B2C and enterprise together: keep two facts per order
The self-serve plan targets individual buyers in several countries. The enterprise plan uses negotiated annual fees, POs, and implementation. Forcing every order onto one model either loads B2C with multi-jurisdiction tax operations, or strips enterprise sales of contract and invoicing capacity. The two paths can use an MoR and a processor separately if the catalog marks which channel can sell, the order stores the real seller, subscription renewals do not drift across channels, and finance can reconcile them apart.
If the enterprise contract also includes third-party seller splits, collection for others, or platform onboarding, the problem has already left ordinary SaaS processor/MoR choice. That needs a separate marketplace, Connect, or platform-payments design. A digital-product MoR account is not a third-party funds rail.
Re-judge after entity, product, buyer, or channel changes
Account approval only proves that the entity, product, and transaction conditions submitted then were accepted. Any of the following can stale the old contract and cover evidence:
| Object that changed | Why the old conclusion may fail | Records to confirm again |
|---|---|---|
| Contracting entity, controllers, or settlement account | Agreement entity, KYC/KYB, tax residence, and funds beneficiary changed | New agreement entity, account review, supplier files, payout method, withholding |
| Product, delivery, or commodity class | MoR sale scope, tax rate, refund rules, and risk grade changed | Product data, tax class, site terms, delivery evidence, review result |
| Buyer country or B2B/B2C mix | Indirect-tax cover, consumer rights, invoices, and local payment requirements changed | Transaction-level tax cover, buyer terms, invoice samples, payment methods |
| Pricing, currency, billing period, or sales contract | Tax-inclusive treatment, documents, renewal mandates, and total cost changed | Price versions, invoices, debit mandates, refunds, and prorating rules |
| Checkout, app store, sales-assisted, or platform channel | Buyer seller, platform rules, and collection chain may change | Seller, provider product, tax owner, and settlement relationship per channel |
| Service product, terms, or data policy | Responsibility scope, fees, and export ability under the same brand changed | Current terms, data addendum, migration note, and termination clauses |
Whether this $100 order’s responsibility model holds depends on five named owners: who contracted with the buyer, who runs the transaction work, who holds decision rights, who takes the economic result, and who controls and keeps the data evidence. If any of those can only be answered with “the platform will handle it,” a long-lived renewal relationship is not ready to sign.
After those five positions have owners, take the same order’s entity, buyer country, B2B/B2C mix, currency, payment methods, invoice requirements, refund rate, settlement account, and exit conditions into the next provider review. Those conditions have to match before public fee tables are comparable. A published rate is only one input.
Frequently asked questions
Is Stripe a payment processor or a merchant of record?
It depends on the product and the transaction. Ordinary Stripe Payments usually process the payment while the merchant remains the seller. Stripe Managed Payments can make Link the merchant of record on covered transactions. A brand name does not replace the product, the transaction scope, and the signed agreement.
After using a merchant of record, do I still have tax work?
Yes. An MoR usually handles VAT, GST, and sales tax on covered transactions. The supplier still has to keep product classification and sale data accurate, and still handles income tax, corporate tax, withholding, and sales outside that cover.
If the merchant of record handles chargebacks, can the supplier still lose money?
Yes. The MoR can receive the dispute and submit evidence. The contract can still debit refunds, chargeback amounts, fees, or a negative balance from the supplier balance and later payouts.
After using a merchant of record, who owns customer data?
Ownership is the wrong test. Check which fields you can access, which uses are allowed, whether ordinary data can be exported, whether payment credentials can transfer, whether the renewal mandate survives, and which history remains after termination.
Can one SaaS use both a payment processor and a merchant of record?
Yes, if the provider supports that transaction scope and the system stores the real seller, tax owner, document source, refund entry, and renewal owner on each order.