When I was building my first SaaS product, I thought payment processing meant picking Stripe, adding a card form, and moving on. It took exactly one email from a German customer asking for a proper VAT invoice to make me realize I had no idea what I was doing.
That kicked off a rabbit hole that ate about multiple hours over 10 days. At the end of it, I finally understood what a merchant of record actually is, and why it matters more than almost any other infrastructure decision you’ll make as a digital product seller.
Here’s what I learned.
The invisible layer underneath every digital transaction
When someone buys your software online, there are really two different things happening at once.
One is the technical act of moving money. A payment gateway captures the card details, a payment processor routes the transaction, and the funds eventually land in your bank account. Most founders understand this part.
The other is the legal act of selling. Someone has to be the named party responsible for that transaction. Someone has to be liable for the VAT collected in Germany, the GST in Australia, the sales tax in Texas. Someone has to handle the chargeback when a customer disputes the charge. Someone has to hold the merchant account, comply with PCI DSS requirements, run KYC checks, and maintain AML compliance.
That entity is called the merchant of record.
If you sell directly through your own checkout with Stripe acting purely as a payment processor, you are the merchant of record. You own all of it. The compliance, the tax remittance, the fraud exposure, the disputes. Every bit of it.
I did not register it until the first EU customer asked for a VAT invoice and I realized I could not explain who was legally responsible for issuing it.
What a merchant of record is actually responsible for
Let me make this concrete. When an MoR is handling your transactions, here is what they own:
Transaction processing and settlement. They accept payments, handle the authorization flow, capture funds, and manage refunds. If a customer wants their money back, the MoR processes it. If a dispute gets filed, the MoR fights the chargeback with the card network, not you.
Tax collection and remittance. This one is enormous and almost always underestimated. Sales tax in the US alone has over 10,000 different jurisdictions. VAT was the first wall we hit. We had buyers in Germany, the UK, and France, and we could not answer basic questions like “which VAT rate applies” and “what the invoice must show” without stopping product work. GST, consumption tax, digital services taxes. An MoR calculates the right tax at checkout, collects it from the buyer, and remits it to the correct authority. You don’t touch any of it.
Regulatory compliance. PCI DSS compliance for handling card data. Know Your Customer obligations. Anti-money laundering checks. These aren’t fun to learn while shipping. We had to deal with invoice formatting, refund policy wording, and dispute evidence much earlier than we expected.
Fraud management. The MoR implements fraud detection, monitors transaction patterns, and eats the losses when fraudulent transactions slip through. Their risk, not yours.
Customer data management. Purchase histories, payment details, transaction records. The MoR handles this in compliance with privacy regulations across jurisdictions.
When you work with an MoR, your statement descriptor shows their name or entity, not yours. That’s the tell. They are the seller of record in the eyes of the bank, the tax authority, and the card network.
Merchant of record vs payment facilitator: they are not the same thing
This is the confusing part, because people use these terms loosely.
A payment facilitator, or payfac, makes it easier for you to accept digital payments. Instead of applying for your own merchant account with a bank, a payfac aggregates you under their master account. Stripe, Square, PayPal when used as a simple payment tool. They handle the technical layer of payment processing.
But a payfac does not take on your tax obligations. They do not handle your chargebacks in the full legal sense. They do not make you compliant with VAT remittance in the EU. You are still the merchant of record. You still carry the liability.
An MoR goes further. They step in as the legal seller. The transaction appears on your customer’s credit card statement under the MoR’s entity. The MoR files the tax returns. When a dispute hits, it’s the MoR’s chargeback ratio, not yours, that’s on the line.
The practical difference: with a payfac, you simplify how you accept payments. With an MoR, you transfer who is legally responsible for the sale.
Who actually needs a merchant of record
Not everyone does, and it’s worth being honest about that.
If you’re selling exclusively in one country, you understand your local tax rules, and your transaction volume is low enough that compliance is manageable, you can run as your own merchant of record with a payment processor underneath you.
The calculus shifts once you are doing about $5,000 a month and have customers in 5 or more countries, because the tax and dispute overhead starts compounding.
Selling internationally. The moment you have customers in multiple countries, you have potential tax obligations in multiple jurisdictions. VAT in Europe, GST in Australia, consumption tax in Japan, digital services taxes that are still being introduced in various markets. Managing this yourself is a real full-time job.
Subscription and usage-based billing. Recurring payments introduce more touchpoints for disputes, failed charges, and regulatory scrutiny. An MoR that handles subscription billing keeps the compliance burden from compounding with your revenue growth.
App developers selling outside app stores. The recent court decisions and regulatory changes around in-app purchases have pushed more developers to handle direct payments. When you bypass the app store, you take on the MoR responsibilities the store was previously handling.
Small SaaS teams that want to stay focused. Every hour you spend on tax remittance or chargeback disputes is an hour you’re not building product. For teams with limited bandwidth, outsourcing MoR responsibilities isn’t laziness. It’s prioritization.
E-commerce and digital product sellers. Digital downloads, SaaS subscriptions, API access, any digital good sold across borders carries international tax exposure that most founders underestimate until they get a compliance notice.
The real benefits nobody puts in the headline
The compliance angle gets all the attention. But the benefits worth thinking about run deeper.
You can sell globally from day one. Without an MoR, expanding internationally means researching tax law in each new market before you can confidently collect money there. With an MoR, that’s already solved. You just turn on a new country.
Your cash flow gets more predictable. An MoR handles settlement timing and reconciliation. You know when money lands, in what currency, and what the deductions were. There’s a reporting and analytics layer you don’t have to build.
You stop being personally exposed to fraud losses. When someone uses a stolen card to buy your product, with an MoR, that’s their problem to absorb. Without one, you eat the chargeback fee and lose the transaction amount.
Chargebacks don’t threaten your payment processing access. High chargeback ratios can get your merchant account terminated. When an MoR is the merchant of record, your direct relationship with card networks is protected. Their chargeback ratio absorbs the hit.
Kelviq merchant of record
At Kelviq, we built merchant of record infrastructure specifically for developers and AI companies running usage-based billing.
The difference is flexibility. You can use Kelviq as your MoR where it makes sense and keep direct processing where it doesn’t. If you want to offload tax liability in the EU but maintain your own merchant account in the US, you can do that. If you need real-time usage metering with compliant invoicing globally, that’s what we built for.
Most MoR solutions were built for SaaS subscription models. Flat monthly pricing, predictable revenue cycles, static customer counts. That model breaks when you’re billing based on API calls, token usage, compute time, or any metric that moves in real time. Kelviq handles usage-based billing natively because that’s the problem we started with.
If you’re selling software globally and dealing with international tax compliance, or if you’re building AI infrastructure where usage can spike 10x overnight and your billing needs to keep up, this is what we’re solving.