What Is a Merchant of Record? Costs and a SaaS Example

A Merchant of Record (MoR) is the entity legally responsible for the customer payment transaction. When you use a third-party reseller/MoR, it sells the covered product to the customer under its agreement and pays you the amount owed. You still build and support the product.

Picture a customer buying a monthly plan for your document-processing app. With a third-party MoR, the provider takes the covered seller role, records the payment and later pays you after applicable deductions. Your app gives the customer access. If the customer needs help processing a document, that question still comes to you.

That's the division you're buying: someone else takes specified responsibilities for the sale while you run the software. A payment processor can move the money without taking that seller role, and different MoRs include different tax, billing and payout services.

In this guide

• What the MoR role covers

• How a SaaS purchase works

• MoR versus processor, gateway and seller of record

• Costs and trade-offs

• Choosing a provider

• Anyway's current scope

What a Merchant of Record does

The MoR deals with the commercial side of the purchase: responsibility for the payment, the payment-provider relationship and obligations attached to the sale. Stripe's explanation of the MoR role covers this distinction. The service you sign up for then adds tools around that role, such as checkout, billing or tax handling.

Here are the questions to bring to a provider, alongside the work your team will keep:

Pay particular attention to taxes and disputes. Providers can offer different levels of tax automation, and managing a chargeback doesn't necessarily mean absorbing its cost. The agreement should make both clear.

What a MoR doesn't automatically replace

If a paid customer can't log in, your team still needs to fix it. Authentication, access rules, product support and accurate product claims stay with you, as do your own income reporting, accounting and applicable employment obligations.

A MoR agreement isn't a universal exemption from local rules. Nor does it make a restricted product acceptable. Review the provider's product policy and seek qualified advice for questions specific to your business or jurisdiction.

How a Merchant of Record transaction works

Return to the document-processing app. Here's how that monthly purchase reaches both the customer's account and the founder's balance:

1. The merchant is approved. The provider reviews the seller and product and confirms the applicable service scope.

2. A product and price are configured. The buyer sees what is included, the billing interval and the final amount required by the checkout.

3. The customer pays. The MoR records the sale under the agreed commercial arrangement.

4. The app verifies the order. A server-side confirmation is matched to the customer's pending purchase.

5. Access is granted. The app creates the subscription entitlement once, even if a notification is repeated.

6. Revenue becomes available. Settlement, fees, refunds, reserves and payout rules determine the amount the developer can withdraw.

Keep the payment, access and payout records separate. The customer has paid even if your withdrawal is still processing, so a payout delay shouldn't cancel their subscription. At the other end, seeing a success-page URL isn't enough to prove they paid.

The SaaS payment webhook guide covers that implementation boundary.

Merchant of Record vs payment processor, gateway and seller of record

Payment processor

A processor handles the movement and processing of payments. In a standard processing arrangement, your business usually remains the merchant responsible for the sale. A provider may separately offer a MoR product, so compare the specific service, not just the company name.

For example, don't treat all Stripe offerings as the same arrangement. Ordinary payments and a separately contracted MoR service can allocate responsibilities differently. Read the product agreement and identify the entity shown as seller.

Payment gateway

A gateway helps transmit payment information and authorization requests. That technical role doesn't itself transfer the legal sale to another business. A branded checkout or an API that accepts a card isn't proof of a reseller relationship.

Seller of record

“Seller of record” emphasizes the party selling to the customer, while “merchant of record” emphasizes payment-related responsibility. Depending on the agreement and business model, one entity may perform both roles or the responsibilities may be separated. Stripe discusses that distinction in its MoR versus seller-of-record guide.

For a SaaS founder, labels are less useful than four questions: who contracts with the buyer, who appears on the invoice, who receives the payment, and who is responsible for the covered taxes and disputes?

Marketplace

A marketplace is a distribution model, not a single legal payment role. Some marketplaces sell as MoR; others connect a seller's own payment account. Check whether it actually solves your payment problem before moving the product there.

What does a Merchant of Record cost?

Many providers charge a percentage plus a fixed amount per successful payment. That is the first line of the calculation, not necessarily the complete cost.

Budget for charges and operating work:

• Transaction charges and conditional surcharges.

• Currency conversion and receiving-bank costs.

• Payout-request fees and minimums.

• Refund treatment, including fees that aren't returned.

• Dispute fees and any losses allocated to you under the agreement.

• Optional services and the internal work still required.

Allow for cash you can't withdraw yet

Reserves and withheld balances affect cash flow, but they aren't automatically fees or permanent losses. Some money may remain unavailable until the agreed release conditions are met; amounts used to cover refunds, disputes or other obligations may not be released to you. Check the amount, reason for the hold and release rules separately from the provider's charges.

When planning a month, estimate both what the service costs and how much cash will reach your account in time to pay your bills. Those are different calculations.

Why order size matters

Suppose a fictional provider charges 4% + $0.50. A $5 payment would incur $0.70, or 14%, while a $50 payment would incur $2.50, or 5%. These are illustrative calculations, not a vendor quote, and exclude taxes and other costs.

For a low-priced API or AI tool, collecting every tiny usage charge separately can make the fixed component expensive. A prepaid pack or a periodically collected bill may better match the product, subject to provider support and customer consent. Metering usage and collecting money don't need to happen at the same frequency.

Compare saved work, not just rates

Ask what your team would have to build or operate without the service. A lower payment fee can leave you spending more time on taxes, refunds or billing. But a broad package also isn't worth paying for if you won't use its tools.

Estimate total operating cost against your actual order values and countries. Don't compare a narrow processor rate to a MoR rate as if they necessarily cover the same work.

When a MoR makes sense for SaaS

If you're a small software team selling across borders, a MoR can take agreed seller responsibilities off your plate. It can also offer an eligible individual a route to collect payments and receive payouts. The useful question is how much of your actual operating work its service takes on.

It can be a poor fit when your product is excluded, the payout route is unusable, a required billing feature is missing, or you need commercial control the agreement doesn't provide. Established companies may also decide that maintaining their own merchant operations fits better.

You'll depend on that provider's approval, settlement process and product decisions. Keep usable order and customer records from the start, so a future change of provider doesn't become an emergency data project.

How to choose a Merchant of Record for SaaS

1. Confirm seller and product eligibility

Use your real identity, business location and product category. Ask whether the provider accepts an individual or requires a company for your circumstances. A successful signup form isn't merchant approval.

2. Check tax services as working capabilities

Ask which markets and transaction types are covered, how the tax amount is represented, what is automated and which records you receive. Separate planned capabilities from launched features. Keep a written record of material service commitments.

3. Test the billing lifecycle

For a subscription, test renewal, cancellation and a failed payment. For a credit product, test fulfillment, consumption and reversals. Confirm the event behavior your app relies on rather than only the first checkout.

4. Verify the money can reach you

Confirm the beneficiary, receiving currency, minimum request, fees and availability rules. A supported customer payment method isn't evidence of a supported seller bank account.

5. Plan a possible exit

Know how to export customers, orders, invoices and reconciliation records. Ask whether and how active subscriptions and payment credentials can move. Don't assume access to a CSV means every payment authorization is portable.

Where Anyway fits, and what to confirm

If you already have a working app, Anyway lets you create a product and price, share a hosted payment link and connect paid orders to your own access rules. It also supports recurring Card/USD subscriptions and merchant payouts. Businesses and individuals can apply; the Business documentation explains the workflow after approval.

There's a material limit to know before choosing it: the MoR scope page identifies Anyway as the legal seller for eligible sales, but says automated per-order tax calculation, collection and remittance hasn't launched. Current orders have no separate tax amount; that doesn't make a sale tax-exempt. Resolve the tax treatment your intended sales require before launch.

For an app with its own accounts and usage limits, the benefit is avoiding a custom checkout interface while keeping fulfillment in your backend. Anyway Agents separately supports controlled spending on paid APIs; its wallet funds are distinct from the revenue you collect from customers.

If those capabilities fit, check your eligibility with Anyway. If a required service is outside the current scope, resolve that requirement before accepting affected transactions.

Frequently asked questions

What does MoR stand for?

MoR means Merchant of Record: the entity responsible for the payment transaction. In a third-party reseller arrangement, the provider takes the covered seller role under its agreement.

Is a Merchant of Record the same as a payment processor?

No. Processing a payment is a technical and financial service; taking the merchant role concerns responsibility for the transaction. One company can offer both kinds of product under different arrangements.

Does a MoR handle all my taxes?

No. Check its live transaction-tax services and contractual scope. Your own income and business obligations are separate, and some features may not be launched or available in your market.

Can I use a MoR without a company?

Some providers accept eligible individuals. You still need identity checks, a permitted product, accurate tax information and a supported payout route. Local obligations may also apply.

Does using a MoR remove chargeback risk?

No. A provider may administer disputes while its agreement still allocates fees, refunds, reserves or losses to the developer. Keep delivery and support records and read the cost terms.

Choose the responsibility you need to transfer

Write down the job you want to stop doing yourself. Is it managing covered transaction taxes, building checkout, or finding a workable payout route? Choose the service that takes on that job, and budget for the work that stays with your team.

You might also like

• Anyway vs Paddle: compare billing scope, fees and payouts.

• Stripe not available in your country?: evaluate legitimate seller routes.

• SaaS payment webhooks: connect verified transactions to product access.