Merchant of Record vs. Payment Processor: Who Owns the Risk?

Choosing between a payment processor and merchant of record software is rarely a technical footnote. It is the decision that determines who answers to tax authorities, who runs refunds and disputes with subscribers, and whose acquiring relationships decide whether a renewal gets approved. Most comparisons of merchant of record vs payment processor stop at tax, yet that is only one of three responsibilities recurring revenue depends on. What follows maps all three: tax and regulatory compliance, customer support and refunds, and payment orchestration.

What a Payment Processor Actually Does

A payment processor supplies the plumbing beneath a transaction: the rails that move money from a customer's card or wallet into a merchant's account. Its role centres on running payments — authorising the charge, routing funds, and securing the technical exchange.

A payment processor typically covers:

• Processing card, wallet, and bank payments
• Payment security and PCI DSS compliance
• Cross-border fund transfers and settlement
• Basic fraud screening at the point of sale

What sits outside that scope is where businesses are most often caught unprepared:

• Tax liability. The merchant remains solely responsible for calculating, collecting, and remitting VAT, sales tax, or GST. The processor moves the gross amount and stops there.
• Tax filing. Processors do not file returns in any jurisdiction, and each country, state, or city carries its own filing calendar and registration threshold.
• Customer support. Billing questions, cancellation requests, and refund conversations all land on the merchant's own support team.
• Refund and dispute operations. The processor provides tooling to respond to a dispute; assembling evidence, meeting deadlines, and running the workflow stays with the merchant.
• Compliance ownership. A processor is not the legal seller of record anywhere, so cross-border compliance, consumer protection rules, and subscription cancellation law stay with the merchant.

The core misunderstanding is treating payment infrastructure and compliance infrastructure as the same thing. They overlap operationally and diverge completely in responsibility.

What Changes Under Merchant of Record Software

Merchant of record software alters the equation at its foundation rather than at its edges. Instead of your business remaining the seller in every jurisdiction, the MoR becomes the official legal entity transacting with the customer.

That single change cascades. The MoR is the name on the receipt, the entity registered with tax authorities, the party holding the acquiring relationships, and the party your subscribers contact when they have a billing question.

Everything that follows in this article is a consequence of that one shift.

Tax and Regulatory Compliance

Tax obligations rarely stay fixed once a business sells digital products internationally. They expand automatically with every new market. One SaaS subscription sold in one country carries one set of rules; the same subscription sold in twenty countries carries twenty overlapping, often conflicting, sets of rules — each with its own registration threshold, filing calendar, and definition of what counts as a digital service.

Why Subscriptions Compound Tax Complexity

Recurring revenue is usually framed as a growth advantage. From a tax standpoint it behaves differently from a one-time sale, because every point in the subscription lifecycle reopens the same question:

• Renewals trigger repeated tax obligations. Each renewal is a new taxable event, recalculated against the customer's current location and the rules in force at that moment — a recurring mechanic at the heart of global subscription billing.
• Cancellations create refund tax adjustments. A refund, partial or full, demands a corresponding tax correction, which grows more intricate across jurisdictions and across reporting periods.
• Upsells generate additional taxable events. Every upgrade or add-on is a fresh sale, so subscription funnel optimization has to be built with tax logic embedded rather than layered on afterwards.
• Regional pricing adds another variable. Charging different prices by region — standard SaaS checkout optimization practice — has to stay reconciled with regional pricing compliance at each price point.

The risk is not that subscriptions are inherently riskier products. It is that compliance effort recurs on exactly the same cadence as revenue.

Mobile App Monetization: App Store vs Web Billing

A second layer appears where app store purchases meet direct web payments. The distinction between app store vs web billing is not cosmetic — it determines which entity owns the tax obligation for a given transaction.

Purchases through the Apple App Store or Google Play generally fall under the platform's own merchant of record status, with the store handling tax on those sales. Web-based payments, introduced to avoid platform fees or enable more flexible pricing, carry no such coverage. This is how web-to-app models quietly move tax jurisdiction back onto the business, often without anyone registering that a handoff occurred.

Upsell paths blur it further: an in-app prompt routing a user to a web checkout for a premium tier crosses the boundary mid-funnel. For mobile app monetization spread across regions, rates and rules can differ not only between countries but between the app and web channels within the same country.

Where Responsibility Lands

Under a payment processor, the merchant is the seller in every jurisdiction. Calculation, collection, remittance, filing deadlines, and any misread local rule are the merchant's to carry.

Under merchant of record software, the MoR is the legal seller and takes on the corresponding weight — calculation, collection, filing, and remittance across the jurisdictions where it is registered, along with the audit conversation itself. In those jurisdictions, the underlying business typically does not need to register separately, which is what allows SaaS tax compliance to scale without headcount scaling alongside it.

Customer Support, Refunds, and Dispute Management

This is the area most MoR comparisons skip, and for subscription businesses it is often the more demanding one. Tax work surfaces on a filing calendar. Support and refund volume arrives every day, scales with subscribers rather than revenue, and shapes your dispute rate as it goes.

The Support Layer Nobody Budgets For

When the MoR is the legal seller, it is also the entity on the receipt and the bank statement — so it is the entity subscribers contact. That is not a technicality. It is an entire operational function that moves off the merchant's plate.

Zotlo manages that layer directly: subscriber billing inquiries, cancellation requests, refund processing, and the renewal communications that sit around them. In practice this covers:

• Billing and charge inquiries — the largest single category of subscription support volume, and the one most likely to become a dispute if it goes unanswered
• Cancellation handling — processed to a consistent standard, in flows built around auto-renewal and negative-option requirements
• Refund execution — issued under the agreed policy, with the tax correction handled at the same time rather than reconciled later
• Renewal notices — advance notification ahead of charges, which several markets now require and which reduces surprise-charge complaints everywhere else
• Multi-language, multi-time-zone coverage — matched to where the subscribers actually are, rather than to where the product team sits

For a business selling into twenty markets, replicating this in-house means a support function staffed across languages and time zones, with billing-system access and refund authority. Most subscription companies discover the cost of that function only after volume forces them to build it.

Refunds Are a Compliance Surface, Not a Support Ticket

Refund handling has moved from customer-service policy to regulated conduct. Negative-option and auto-renewal rules — ROSCA and FTC enforcement in the US, consumer rights directives in the EU, and equivalent regimes elsewhere — govern how cancellations must be offered, how renewals must be disclosed, and how promptly refunds must be issued. Several recent enforcement actions against subscription businesses have turned on cancellation friction rather than on anything to do with the product.

Under a processor model, that compliance sits with the merchant, and so does the enforcement risk. Under an MoR, the provider is the seller consumers transact with, so cancellation flows, renewal notices, and refund handling are built and maintained to a standard the provider applies across its portfolio.

There is a direct financial link between this and disputes: a customer who cannot find the cancel button, or who waits four days for a reply, files a chargeback instead. Refund operations and dispute rate are the same problem measured at two different points.

Why Dispute Rates Stay Your Problem — Even Under an MoR

One misconception is worth correcting directly, because it leads businesses to relax exactly where they should not.

Working with an MoR does not dilute your dispute performance into a larger pool. Card schemes and acquirers attribute disputes at the level the cardholder actually sees — the statement descriptor tied to your product — so your app's chargeback rate remains identifiable as your app's chargeback rate, whatever entity sits above it in the structure.

The context makes this matter more than it used to. The Visa Acquirer Monitoring Program consolidated Visa's earlier fraud and dispute programs into a single combined ratio measured against total settled transactions, and on 1 April 2026 the merchant "Excessive" threshold tightened from 2.2% to 1.5% across the US, Canada, the EU, and APAC. LATAM was already at that level; CEMEA remains at 2.2%. Merchants above threshold face per-transaction fees in the months they exceed it, and a separate enumeration ratio tracks card-testing traffic. The ratio is counted by transaction, not by value, which puts high-volume, low-price subscription businesses — the typical mobile app monetization profile — under disproportionate pressure.

So the honest framing is this: an MoR gives you the operational machinery to keep disputes low — descriptor clarity so subscribers recognise the charge, support that answers before frustration escalates, refunds issued rather than disputed, and pre-dispute resolution through issuer alert networks. What it does not give you is permission to stop watching the number. Product experience, cancellation friction, and marketing claims all still drive the rate, and all of those remain yours.

Payment Orchestration and Authorisation Performance

This one rarely appears in a compliance discussion, because it is not a compliance question. It is revenue that quietly fails to arrive.

Local Acquiring and Authorisation Rates

A card issued in Brazil or Indonesia, processed through a single European acquirer, faces materially higher decline rates purely because of the cross-border path it travels — before anything about the customer or their balance enters the picture. Those declines are indistinguishable from churn in your reporting, and no line item anywhere labels them.

Payment orchestration addresses this at the routing layer: transactions route through an acquirer in the cardholder's own market, with fallback routing when a primary acquirer degrades. Under a single-processor setup, you get one path per transaction and no alternative when it fails.

For a business selling into twenty markets, matching that under a processor model means acquirer relationships, entity structures, and settlement accounts in each of them. An MoR already holds them, which is why authorisation rate is often the fastest measurable improvement after migration.

Retry Logic, Card Updaters, and Network Tokens

Involuntary churn — subscriptions lost to failed payments rather than cancellations — accounts for a substantial share of total subscription churn across the industry. Recovering it depends on infrastructure the merchant usually does not control:

• Decline-code-aware retries. Insufficient funds is a timing problem best retried near payroll cycles; "do not honour" is an issuer decision that aggressive retries can entrench; an expired card cannot be retried into success at all. Flat retry schedules treat all three identically.
• Account updater access. Visa Account Updater and Mastercard Automatic Billing Updater refresh reissued and expired credentials automatically, though enrolment is managed at acquirer and processor level, with coverage varying by network, issuing bank, and country.
• Network tokenisation. Tokenised credentials survive card reissuance and typically authorise at higher rates than raw card numbers.
• MIT and CIT flagging. Recurring charges must be correctly flagged as merchant-initiated. Mis-flagged transactions draw unnecessary authentication challenges and avoidable declines — a technical detail with direct revenue consequences on every renewal.

Local Payment Methods and Currency

Cards are not the default everywhere. In markets where domestic wallets, bank transfers, or carrier billing dominate, supporting only cards caps your addressable market well below your traffic — and a subscriber paying by domestic wallet is never exposed to card expiry at all.

Currency matters for the same reason. Charging in the customer's own currency removes the foreign-transaction fee that turns a satisfied subscriber into a cancellation, and removes the exchange-rate variance that makes each renewal look slightly different on their statement.

Who Owns What in Each Model

Making the Choice

A payment processor is the right answer for a business selling primarily in one jurisdiction, with in-house tax capability and a support function already sized for its subscriber base. Direct processing is cheaper per transaction, and control over the payment stack has real value when you have the team to exercise it.

The calculation changes at the point where you cross borders, bill on a recurring cadence, or run high transaction volumes at low ticket prices. There the three start compounding each other: tax registrations multiply per market, support and refund volume scales with subscribers rather than with revenue, and every percentage point of authorisation rate you cannot influence is revenue leaving without a trace.

The question is not which model is better in the abstract. It is which of these functions you are equipped to own — and whether the ones you are not equipped to own are visible in your reporting yet.

FAQ About Merchant of Record vs. Payment Processor

Who is legally responsible for VAT under merchant of record software?

The MoR becomes the legal seller of record and takes responsibility for calculating, collecting, and remitting VAT to the relevant tax authorities in the jurisdictions where it is registered, removing that obligation from the underlying business in those jurisdictions.

Does a merchant of record handle customer support and refunds?

Yes — that is one of the main operational differences. Because the MoR is the seller on the receipt and the statement, subscriber billing inquiries, cancellation requests, and refund processing run through the MoR rather than the merchant's own support team. Specific scope and refund policy are set in the provider agreement.

Does working with an MoR lower my chargeback rate automatically?

No. Disputes are attributed at the level the cardholder sees, so your product's dispute performance stays identifiable as yours. What an MoR provides is the machinery that keeps the rate down — recognisable statement descriptors, responsive billing support, refunds issued before a dispute is filed, and pre-dispute resolution through issuer alert networks. Product experience and cancellation friction still drive the number.

Can a payment processor improve authorisation rates as much as an MoR?

Only within its own acquiring footprint. Where a processor holds local acquiring in your key markets, the difference narrows considerably. Where it does not, cross-border routing caps your approval rate regardless of how well your checkout is optimised.

How does tax compliance differ for mobile app monetization?

It depends on the channel. App store sales are generally covered by the platform's own MoR status, while direct web sales and cross-platform payments routed outside the store fall to the business or its chosen MoR partner.

What happens during a tax audit under each model?

With a payment processor, the business responds directly to the tax authority and supplies its own documentation. With merchant of record software, the MoR, as legal seller of record in the jurisdictions where it is registered, typically manages that process on the business's behalf.