Switching payment processors without breaking your affiliate program

Changing your payment processor is stressful enough without wondering whether it will quietly kill your affiliate commissions. The short answer: it will not. Multiple Reditus customers have switched, in both directions (Paddle to Stripe and Stripe to Paddle), and it is one of the more straightforward migrations we support.

This guide explains what actually has to happen, what you control, and what Reditus handles.

The one thing that matters

Reditus already holds your referral data: who referred whom, when, and under which commission terms. That does not live in your payment processor, so changing processors does not touch it.

What Reditus needs is simply this: keep receiving your payment data, and do not send the same payment twice. That is the whole requirement. Everything else is detail.

What you control, and what we handle

You decide the switch moment and manage your own billing. The important part is on your side: making sure your customers are not charged twice during the transition. Teams usually pick a clean boundary, often the start of a billing month, and handle their own migration of subscriptions.

We follow your process. There is no Reditus-mandated sequence. The practical recommendation is: sort out your internal billing process first, in whatever way converts best and works for your customers, then tell us how and when you are switching. We just need to know where the next payment is going to happen so we can make sure that data lands.

Sending payment data after the switch

Which path you use depends on where you are moving to:

• Moving to Stripe: connect the native Stripe integration and payments flow to Reditus automatically. See Connecting Stripe.
• Moving to Paddle, Chargebee, PayPal, or another processor: forward payment events from your backend through the Payments API.

You can run either path, and the commission logic on the Reditus side is identical.

Idempotency keys stop double commissions

Every payment you send through the Payments API carries an idempotency key: a value tied to one specific transaction. It is required, and it exists for exactly this situation.

If the same payment reaches Reditus more than once (a retry, an overlap during the switch, a replayed webhook), the idempotency key means the commission is calculated once and only once. So even if your transition period gets messy, your affiliates do not end up with duplicate commissions and you do not end up reconciling them by hand.

Do referrals need to be re-mapped?

No. Your referrals already exist in Reditus with their affiliate attached. Switching processors means changing where payment data comes from, not rebuilding the relationships behind it. As soon as payments arrive from the new processor, commissions continue generating as before.

One useful case to know about: if you are switching to matching on unique IDs (your own customer or account IDs, rather than email addresses) and your existing referrals do not have those IDs attached yet, contact support. We can bulk-upload the IDs onto your existing referrals so old and new referrals are matched the same way.

Why unique IDs make this easier

If you are already building an API integration, send a unique customer ID alongside every payment, and register that same ID at signup.

Matching on an ID you own means attribution never depends on your payment processor or on an email address a customer can change at checkout. Switch processors later and the program simply continues. If you are on a merchant-of-record platform, this matters even more: read what a merchant of record changes for your affiliate program.

What stays the same through a switch

• Affiliates keep their existing links. Nothing changes on their side, and they do not need to do anything.
• Existing commission terms, tiers, and commission lengths continue to apply.
• Historical referrals, commissions, and reporting stay intact.
• Payouts continue on the 1st of the month above your threshold.

A short checklist

1. Plan your billing migration internally, including how you avoid double-charging customers.
2. Pick the switch moment, ideally a clean billing boundary.
3. Tell us when it happens and which path you will use (native Stripe connection or the Payments API).
4. Make sure payment data flows from the new processor, with idempotency keys, from that moment on.
5. If you are moving to unique-ID matching, ask support about bulk-uploading IDs onto existing referrals.
6. Check your first post-switch payouts to confirm commissions are generating as expected.

FAQs

Will my affiliates lose their links or history when I change payment processor?

No. Affiliate links, referral history, and commission terms live in Reditus and are unaffected by your billing stack.

Could affiliates be paid twice during the transition?

Not if payments carry idempotency keys, which are required on the Payments API. The key ties a commission to one specific transaction, so a payment that reaches Reditus more than once is only counted once.

Do I need to re-import my referrals?

No. Reditus already has them. You only need payment data to start arriving from the new processor.

We match on email today and want to move to unique IDs. Is that possible mid-flight?

Yes. Start sending unique IDs with new payments and signups, and contact support to bulk-upload IDs onto your existing referrals.

Is there a recommended time to switch?

Whatever works for your billing. Most teams choose the start of a billing month because it makes reconciliation cleanest. Tell us the plan and we will make sure the data side lines up.