Merchant of Record and Affiliate Programs: What Actually Changes

If you bill through Paddle, Lemon Squeezy, or another merchant of record, you have probably run into a wall when shopping for affiliate software: nearly every tool in the category leads with "native Stripe integration," and you are not on Stripe.

Here is the honest version of what a merchant of record means for your affiliate program: less than you would expect, with one specific gotcha that quietly breaks attribution if nobody warns you about it. This article covers what changes, what does not, and the one setup decision that saves you from a painful migration later.

What a merchant of record actually does

With a normal payment processor, you are the seller. You collect the money, and you are responsible for sales tax and VAT in every jurisdiction where you have customers.

With a merchant of record (Paddle and Lemon Squeezy are the best known in B2B SaaS), the platform becomes the legal seller of your product. They take the payment, they handle global VAT and sales tax, they manage compliance and chargebacks, and they pay you out. In exchange they take a larger cut than a pure processor would.

For a small team selling internationally, that trade is often worth it. The tax compliance alone can save a founder weeks per year. But it does change the shape of your data, and that is where affiliate tracking comes in.

What changes for your affiliate program

One thing, mostly: you will use an API instead of a one-click payment integration.

Affiliate platforms built around Stripe read your payment events directly from your Stripe account. Under a merchant of record, those events live with the platform, not with you, in a structure the affiliate tool was never built to read. So instead of connecting an account, your backend forwards payment events to your affiliate platform.

With Reditus that means the Payments API. You send payment data, Reditus matches it against the referrals in your program, and commissions generate only when a payment belongs to a referred customer. Everything else is ignored. Honest estimate: about four hours of developer time, and you can test the whole flow in a sandbox before going live.

That is the cost. It is real, but it is a one-time cost, and it buys you something worth having (more on that below).

The one gotcha that breaks attribution

This is the part almost nobody tells you, and it is specific to merchant-of-record setups.

When a customer buys through a merchant-of-record checkout, they often fill in their details fresh. That means the email they type at checkout can be different from the email they signed up with. Someone signs up with their work address, then pays with a billing address or a personal one. Two emails, one human.

If your affiliate attribution relies on matching emails, that customer silently stops matching. The referral was tracked, the payment came in, and the commission never generates. Your affiliate assumes your tracking is broken, and honestly, from their side, it was.

The fix takes about ten seconds. When you build the API integration, send a unique identifier (your own internal customer or account ID) alongside the payment, and register the same identifier at signup. Now matching happens on an ID you control, not on an email the customer can change at checkout.

Our standing recommendation is to always send the unique ID, even when the email looks reliable. You are already writing the integration; adding the ID is a marginal cost during work you are doing anyway, and it removes an entire category of "why didn't this commission generate" support tickets.

There is a bonus reason, which deserves its own section.

Unique IDs are switching insurance

Merchant-of-record pricing is a trade. Some companies decide, usually as they scale, that the cut is no longer worth the convenience, and they move to a direct processor. We see companies move from Paddle to Stripe for exactly that reason.

Here is what usually makes that migration painful: your affiliate program is stitched to your old payment data. New processor, new customer records, and suddenly the link between "this affiliate referred this customer" and "this customer just paid" is gone. Recurring commissions that should run for months quietly stop.

If you were already sending unique IDs, that problem disappears. The identity of the customer never lived in the payment processor; it lived in an ID you own. Change processors, keep sending the same IDs, and the program continues as if nothing happened.

So the decision to send unique IDs is not really about email reliability. It is about not letting your billing stack hold your affiliate program hostage.

What does not change

Once payment data reaches Reditus through the API, the platform does not care where it came from. A merchant of record, a direct processor, or a custom billing system all behave identically from that point on:

• Recurring commissions run on your schedule and percentage, for the commission length you set.
• Refunds are handled automatically. Send refund data to the refund endpoint and the full commission is rejected before payout. No manual step, and no exposure to buy-then-refund fraud. (Partial refunds are not supported: any refund rejects the whole commission.)
• Payouts are generated on the 1st of the month above your threshold, with the same processing fees as any other setup.
• Fraud detection works the same, including self-referral detection and automatic rejection of referrals from paid ads on your brand terms.
• Network access is unchanged. Being on a merchant of record does not affect your access to the 26,000+ B2B SaaS affiliates in the Reditus network or to AI affiliate discovery.

One honest limitation: coupon-code tracking requires a native Stripe connection. On a merchant-of-record setup your affiliates promote with tracked links, which covers the full attribution flow, but there is no coupon-based attribution.

Setting it up

The tracking side is identical to any other Reditus setup, and the payment side is where the API comes in:

1. Install the tracking script in your site header. It places the attribution cookie when someone clicks an affiliate link. No cookie consent banner needed: it is an attribution-only cookie with no PII.
2. Add the sign-up snippet at your registration step, and register your unique customer ID here.
3. Forward payment events from your backend to the Payments API, including that same unique ID. Test on the sandbox first, then switch to production.

Full walkthrough in the payment-processor setup guide, and processor-specific overviews for Paddle and Chargebee.

Should the merchant of record matter when choosing affiliate software?

It should be a filter, not a dealbreaker. Ask any vendor you are evaluating:

• Can we send payment data through an API, or is a native processor connection the only path?
• Can attribution run on our own customer IDs rather than email matching?
• What happens to existing commissions if we change payment processors later?

Tools that can only read a Stripe account will either say no or quietly leave you doing manual reconciliation every month. If you want a broader view of the category first, our comparison of 14 SaaS affiliate platforms covers who works with what.

Reditus connects natively with Stripe and works with Paddle, Chargebee, PayPal, and any other processor that can send payment data through the API, from $99 per month with a 14-day free trial. Start a free trial or book a demo if you would rather walk through your setup with us first.

Frequently asked questions

Can I run an affiliate program if I use Paddle or another merchant of record?

Yes. You forward payment events to your affiliate platform through an API instead of connecting a payment account. With Reditus this takes about four hours of developer time, and customers run their programs this way today.

Why does the customer email sometimes not match under a merchant of record?

Merchant-of-record checkouts often ask customers to fill in their details again, so the email used at checkout can differ from the one used at signup. If attribution depends on email matching, those payments will not match the referral. Sending a unique customer ID alongside the payment solves it permanently.

Do refunds and chargebacks work differently with a merchant of record?

No. Send refund data to the refund endpoint and the full commission is rejected automatically before payout, exactly as with any other API setup.

What happens to my affiliate program if I switch from Paddle to Stripe?

If you send unique customer IDs with your payment data, nothing breaks: attribution is tied to identifiers you control, not to the processor. This is the main practical reason to send unique IDs from day one.

Does Lemon Squeezy's built-in affiliate feature cover this?

Lemon Squeezy includes a basic affiliate feature, which can be enough when you are starting out. What it does not give you is a network of affiliates who can discover your program, AI-assisted recruitment, or the ability to keep your program when you change billing platforms. Those are the reasons companies move to dedicated affiliate software.

Can affiliates use coupon codes on a merchant-of-record setup?

No. Coupon-code tracking requires the native Stripe connection. On other setups affiliates promote with tracked links.