On this page
A customer explained my refund policy to me
A customer explained my own refund policy to me this week. He was wrong. Confidently wrong, quoting terms that weren’t mine, weren’t Paddle’s and, as far as I can tell, weren’t anybody’s.
I approved the refund anyway.
That can read like giving in to whoever writes the firmest email. It wasn’t. It was the moment I remembered who had actually sold him the product, and it wasn’t me. Selling through a merchant of record changes who the buyer has a contract with, and most of us who sell software that way behave as if it doesn’t.
With a merchant of record, you are not the merchant
Here’s the part nobody selling software likes saying out loud: with a merchant of record, you are not the merchant. Paddle is. The buyer’s contract is with them.
That is the whole point of the model. The merchant of record is the legal seller. It takes the payment, calculates and remits sales tax and VAT, issues the invoice and deals with chargebacks. You supply the product and receive a payout. You hand over a lot of tax and compliance work, and in exchange you hand over the position of seller.
| Selling directly with a payment processor | Selling through a merchant of record | |
|---|---|---|
| Legal seller | You | The MoR |
| Buyer’s contract | With you | With the MoR |
| Sales tax and VAT | Your responsibility | Handled by the MoR |
| Invoice | Issued by you | Issued by the MoR |
| Chargebacks | You respond | The MoR handles them |
| Refund terms | Yours to write | The terms the buyer accepted from the MoR |
I’m a supplier with strong opinions and no standing.
The trouble is that it doesn’t feel that way day to day. Your product name is on the checkout, the receipt is for your product, and the unhappy email lands in your support inbox. Everything about the experience says it’s your shop. The contract says otherwise.
Who is the seller and who holds the money are the first decisions in any payment setup, and they shape support more than most people expect. We looked at the same question from the other side in what we learned building non-custodial payments at P2Flux, where the product never holds funds at all.
Why I approved the refund anyway
So it was never my policy against his. It was his imagination against a document neither of us had read properly.
Look at what I would have been arguing with. My own pages are not the contract. The terms he quoted were not the contract either. The real one was Paddle’s, accepted by him at checkout. If I had dug in, the best outcome was winning a debate about a contract I’m not a party to.
Winning would have changed nothing that mattered. A buyer who doesn’t get his way from the supplier can go to the seller, or to his bank. Either way the decision is made by someone else. My opinion isn’t an input.
This isn’t a rule that the customer is always right. He wasn’t. It’s a rule about not defending, from memory, a contract that belongs to someone else. A refund costs one sale. An argument I have no standing in costs time and goodwill, and very likely the same sale anyway.
Read the terms your buyer actually accepted
I’ve read it now. Much shorter than the argument.
If you sell through Paddle or any other merchant of record, find the terms the buyer accepts at checkout and read them once, start to finish. These are the things I’d look for:
- Which documents apply. The MoR’s buyer terms, plus any terms of yours that the checkout links to. Know which ones the buyer was actually shown.
- What they say about refunds. The window, who decides and any conditions. Write the answer down in one sentence you can paste into a reply.
- Who the buyer contacts. Whether refund requests should go to you, to the MoR or to either. That decides what your support inbox does with the email.
- What is left for your own terms. Usually the licence: what the buyer may do with the software, how many sites or seats, what support includes. Your terms should cover that ground, not compete with the seller’s terms on refunds.
- Consumer law above both. Both documents sit under the law of the buyer’s country. In the EU, consumers get a 14-day right of withdrawal on distance purchases, and digital content is exempt only when the buyer agreed to immediate delivery and acknowledged losing that right.
None of this needs a lawyer for a first read. It needs one sitting and the willingness to find out you were wrong about your own business.
Make your own pages agree with the contract
Once you know what the buyer agreed to, check everything you publish that talks about money. Customers don’t read the MoR’s terms either. They read your pricing page, your FAQ and old support replies, mix them with something they saw elsewhere, and arrive with a policy nobody wrote.
- Pricing and FAQ pages. Remove refund promises or refusals that the real terms don’t support. A line like “no refunds” on your page doesn’t overrule the seller’s terms. It just gives the customer something wrong to quote.
- Licence page. Keep it about the licence. Link to the buyer terms for anything about payment, tax and refunds.
- Support replies. Keep one saved reply for refund requests that states the actual position and links to the terms, so whoever answers the inbox gives the same answer every time.
- Checkout copy. If you control any text near the buy button, make sure it doesn’t contradict the terms the buyer accepts a few seconds later.
The test is easy to state: when a customer quotes a policy at you, it should be the real one.
Keep your app in step when a refund happens
A refund approved at the merchant of record is still your problem on the product side. The money goes back through their system, but licence keys, subscriptions, seats and downloads live in yours. If nothing connects the two, a refunded buyer keeps working access and you find out months later.
Paddle and other merchants of record send webhooks for these events. Handle refunds and chargebacks the way you handle a new purchase: verify the signature, record the event against the order, revoke or downgrade access, and make the handler safe to run twice, because webhooks get retried. In Laravel, Cashier has a Paddle integration that covers the webhook plumbing and subscription state. Anything specific to your product, such as licence keys, still needs your own listener.
Then test it with a refund in your MoR’s sandbox, not only a purchase. Purchases get tested because they make money. Refunds tend to get tested the first time a customer asks for one.
Read the document before the next argument
The lesson I took from this wasn’t really about refunds. It was about knowing which documents govern your business, and reading them before someone else explains them to you. A merchant of record takes a lot of work off your hands. The price is that some decisions were never yours to make, and pretending otherwise only produces arguments you can’t win.
If you sell through an MoR and have never read what your buyer agreed to, read it before the next refund email arrives, not while you’re drafting the reply. And if you’re wiring an MoR into a Laravel product and want refunds, licences and access to stay in step, that is work we do.
Frequently asked questions
What is a merchant of record?
A merchant of record is the company that legally sells your product to the buyer. It takes the payment, handles sales tax and VAT, issues the invoice and deals with chargebacks, then pays you out as the supplier. Paddle is a well-known example for software.
Who sets the refund policy when you sell through Paddle?
The buyer’s contract is with Paddle as the merchant of record, so the terms the buyer accepted at checkout govern refunds, within the consumer law of the buyer’s country. Your own pages should match those terms rather than set a competing policy.
Should I refuse a refund if the customer quotes the wrong terms?
Not on the strength of your own pages alone. If you sell through a merchant of record, the real terms belong to the seller, and a refund you refuse can still be granted by the MoR or reversed through the buyer’s bank. Check the actual terms first, and when in doubt a refund usually costs less than the argument.
