How to handle affiliate commissions on Stripe refunds and upgrades

A Stripe refund is not only a customer support event. In an affiliate program, it changes the revenue that justified the commission.

If the payout ledger does not follow that change, one of two things happens: the merchant pays commission on revenue it no longer keeps, or the affiliate sees a correction with no audit trail. Both cases create reconciliation questions.

This guide covers the operating model for SaaS teams that bill through Stripe: full refunds, partial refunds, paid commissions, unpaid commissions, and upgrade invoices that can create duplicate commission entries if they are treated like new customers.

For the broader setup, read how to set up an affiliate program with Stripe. For the architecture question, see Stripe affiliate software: native vs integration.

---

Stripe refunds change the commission basis

Stripe lets you refund a charge in full or in part. Its create refund API also supports refund amounts below the original charge amount, which is the payment truth your affiliate ledger has to follow.

The affiliate ledger should answer four questions for every refunded payment:

• Which conversion did this refund affect?
• Was the commission still pending, already approved, or already paid?
• What amount of revenue remains after the refund?
• What correction should be visible to the merchant and the affiliate?

If the system only marks a payment as "refunded" without updating commissions, your reported affiliate CAC is wrong. If it silently edits historical amounts, the affiliate loses the audit trail.

A clean model records the refund, keeps the original commission history, and adds an explicit correction when money has already moved.

Use a status model before calculating clawbacks

A SaaS affiliate program needs more than "sale" and "paid".

State	Meaning	Refund treatment
Pending commission	Payment received, refund window still open	Reject or cancel the commission before payout
Approved commission	Refund window passed, not yet paid	Move it back out of payable balance or create a correction
Paid commission	Affiliate has already been paid	Create a negative clawback line
Refunded conversion	Underlying Stripe payment has been reversed fully or partly	Store the refund amount and reason
Clawback line	Negative commission created after payout	Keeps the ledger auditable

The exact labels can differ by platform. The principle does not: never hide the original commission, and never pay out without checking the refund window.

Full refund before payout

The simplest case is a full refund before the affiliate has been paid.

Example:

• Customer pays 200 EUR
• Commission rate is 20%
• Pending commission is 40 EUR
• Customer receives a full refund during the refund window

The right action is not a negative payout. Nothing has been paid yet. The commission should be rejected or cancelled with a reason such as Payment refunded.

This is why payout timing matters. A 14 or 30 day holding period lets the merchant handle normal refund requests before moving commission into a payable state. The article on how to pay affiliates in SaaS covers payout timing in more detail.

Partial refund after payout

Partial refunds need proportional math.

Example:

• Customer pays 200 EUR
• Affiliate commission is 20%, so the paid commission is 40 EUR
• Customer receives a 100 EUR partial refund
• Half of the revenue was reversed

The commission correction should also be half of the original commission: -20 EUR.

That clawback should be a separate negative commission line. It keeps the ledger readable:

Line	Amount
Original paid commission	40 EUR
Refund clawback	-20 EUR
Net commission after refund	20 EUR

This is the part many affiliate tools handle poorly. They may mark the order refunded, but leave the already paid commission untouched. Or they may overwrite the original commission, which makes reconciliation harder.

RefCampaign records refund-driven clawbacks as explicit negative commission lines for Stripe refunds. Unpaid commissions are rejected; paid commissions get a prorated clawback.

Refund arrives before the conversion exists

Webhook order is not guaranteed in the way operators wish it were. A refund event can arrive before the affiliate conversion has been created, especially when systems process billing events asynchronously.

The safe path is to park the refund with its Stripe refund ID and retry after the conversion exists.

That matters for two reasons:

1. The merchant should not lose the refund adjustment because of event timing.
2. The same refund should not create two clawbacks during retries.

Stripe's refund webhook update exposes refund-level events such as refund.created, which helps systems work with the refund ID directly instead of relying only on the updated charge object.

Upgrades are a separate accounting risk

Upgrades are not refunds, but they create a similar ledger problem: the invoice amount changes after the original acquisition.

When a customer moves from 49 EUR/month to 99 EUR/month, Stripe can create a prorated invoice. If your affiliate system treats that invoice like a new acquisition, you can double-count the customer.

A safe policy starts with a decision, not code:

• Do affiliates earn on expansion revenue?
• If yes, is it recurring, one-time, or capped?
• If no, should upgrade invoices be excluded from acquisition commission logic?
• How are prorations separated from normal renewal invoices?

For one-time acquisition commissions, the safest rule is to only create the acquisition commission on the first paid subscription invoice. Upgrade invoices should not create a second referral. For recurring commission programs, define whether expansion MRR is commissionable before launch.

Checklist for Stripe affiliate refund handling

Use this checklist before paying commissions:

• The refund window matches your customer refund policy.
• charge.refunded or refund.created events are processed.
• Refunds are linked to the original Stripe charge or payment.
• Partial refunds create proportional commission corrections.
• Paid commissions are corrected with negative clawback lines.
• Unpaid commissions are rejected instead of clawed back.
• Refund IDs are used for idempotency.
• Refunds that arrive before conversion creation are retried.
• Upgrade and proration invoices cannot create duplicate acquisition commissions.
• The affiliate can see why a commission changed.

If an affiliate platform cannot answer these points, expect manual reconciliation.

The practical rule

Do not calculate affiliate payouts from gross Stripe payments alone. Calculate them from revenue after refund policy, commission status, and payout timing.

RefCampaign keeps Stripe close to the commission ledger: refunds can reject unpaid commissions, create prorated clawbacks on paid commissions, and leave an auditable trail for the merchant and affiliate.

View pricing to check whether the Stripe-native workflow fits your program.