Affiliate Tracking Without Sharing Your Customer Data

Most affiliate software asks for a lot of access. Connect your payment account, hand over your customer records, let a third party read the transactions that make up your business. For plenty of teams that is a fine trade for the convenience. For others it stalls in a security review, a procurement questionnaire, or a conversation with a data protection officer that nobody wants to have twice.

The good news: affiliate attribution does not actually require most of that data. This article explains what tracking genuinely needs, and how to run a full affiliate program while keeping your customer database inside your own systems.

What affiliate tracking actually needs

Strip an affiliate program down to its mechanics and there are three moments that matter:

1. A click. Someone follows an affiliate link. Something has to remember which affiliate sent them.
2. A signup. That visitor becomes a user, and the referral needs to be recorded against the affiliate.
3. A payment. When the referred customer pays, a commission is calculated.

That is it. Notice what is missing from that list: names, addresses, support history, usage data, and every other field in your customer table. None of it is required to attribute a sale to an affiliate.

The click: an attribution-only cookie

When someone clicks an affiliate link, the Reditus tracking script places a cookie that records which affiliate the click came from. That cookie holds attribution data, not personal data. There is no profile, no cross-site advertising identity, and no personal information stored in it.

Because it stores no personal data and is not used for advertising, this cookie does not require a consent banner. That is worth knowing before you assume affiliate tracking means adding another toggle to your cookie dialog.

The signup: use an ID you own, not an email

At registration, the sign-up snippet registers the referral. You can identify that customer in one of two ways: by email address, or by a unique identifier of your own such as your internal customer or account ID.

The second option is the interesting one. If you send your own ID, Reditus never needs the customer's email address to run attribution. Your users are, from the platform's perspective, opaque identifiers that only mean something inside your systems.

There is a practical bonus beyond privacy: an ID you control cannot drift. Email addresses change, and on merchant-of-record checkouts customers frequently pay with a different address than the one they signed up with, which quietly breaks email-based matching. An internal ID never has that problem.

The payment: two ways to send only what is needed

This is where teams usually expect to hand over payment-account access. You do not have to.

Option one: forward payments through the API. Instead of connecting a payment account, your backend sends payment events to the Reditus Payments API. You choose what each event contains: a unique ID and an amount is enough. Reditus matches the payment against known referrals and only generates a commission when there is one. Everything else is ignored.

Option two: send data for referred customers only. If forwarding all payments is more than you want to share, query the API first to see which referrals exist in your program, then send payment data only for those specific customers. Payments from customers who never came through an affiliate never leave your systems at all.

Both paths take roughly four hours of developer time, and you can test the whole flow in a sandbox environment before anything touches production.

What this looks like in practice

Put together, a data-minimal setup looks like this:

• Your customer database stays where it is. No payment-account access is granted.
• Attribution runs on identifiers you generate and control.
• The only payment information leaving your systems relates to customers who arrived through an affiliate.
• Refunds still work: send refund data to the refund endpoint and the full commission is rejected automatically before payout.

Everything else about the program is unchanged. Recurring commissions, tiers, automated payouts, fraud detection, and access to the network of 26,000+ B2B SaaS affiliates all behave the same as on any other setup.

The honest trade-offs

Three things you should weigh before choosing this path:

It costs developer time. A native Stripe connection is an authorization click. The API route is a few hours of work. If your team has no capacity right now, the native connection is genuinely easier.

Coupon-code tracking requires the native Stripe connection. On the API path, affiliates promote with tracked links. That covers full attribution, but there is no coupon-based attribution.

You own the data flow. Sending less data means you are responsible for sending the right data. Idempotency keys, which are required, make this safer by guaranteeing a payment is never counted twice, but the integration is yours to maintain.

For many teams the native Stripe connection remains the right answer, and it is what most Reditus customers use. The point is that it is not the only answer, and "we cannot give a third party access to our billing data" does not have to be the end of the conversation.

Getting started

1. Install the tracking script in your site header.
2. Add the sign-up snippet at registration, sending your own unique customer ID.
3. Forward payment events (or only the ones tied to referrals) to the Payments API with idempotency keys.

The full walkthrough is in the payment-processor setup guide, and processor-specific overviews are available for Stripe, Paddle, and Chargebee.

Want to talk it through with someone before committing developer time? Book a demo and we will walk through your setup and what the integration would actually involve.

Frequently asked questions

Does affiliate tracking require sharing our customer database?

No. Attribution needs to know which affiliate a click came from, that a signup happened, and that a payment occurred. It can run entirely on identifiers you generate, without names or email addresses.

Does the Reditus tracking cookie store personal data?

No. It stores attribution data so a referral can be credited to the right affiliate. It is not used for advertising and does not build a personal profile, so it does not require a consent banner.

Can we avoid sending customer email addresses entirely?

Yes. Register your own unique customer ID at signup and send the same ID with payment data. Attribution then runs on your identifier rather than on an email address.

Can we send payment data only for referred customers?

Yes. Query the API for the referrals in your program and send payment data only for those customers. Payments from everyone else never leave your systems.

Do we still get automatic refund handling?

Yes. Send refund data to the refund endpoint and the full commission is rejected before payout. Partial refunds are not supported: any refund rejects the entire commission.

Is this slower to set up than connecting Stripe?

Yes, honestly. The native Stripe connection is a single authorization; the API path is about four hours of developer time. You are trading setup time for control over what data leaves your systems.