Siren

How Refunds Work

What happens in Siren when a customer gets a refund: how conversions, obligations, and payouts are affected.

Last updated: April 10, 2026

How Refunds Work

When a customer gets a refund, Siren needs to unwind the affiliate commission that was created from that sale. This page explains what happens automatically and what, if anything, you need to handle yourself.

What triggers a refund

Siren does not process refunds directly. Instead, it listens for status changes in your connected commerce plugin (WooCommerce, LifterLMS, Easy Digital Downloads, or NorthCommerce). When an order moves to a refunded, cancelled, failed, or trashed status, the integration fires a RefundTriggered event and Siren begins reversing the records tied to that order.

You do not need to tell Siren about a refund. As long as the refund happens inside your commerce plugin, Siren picks it up automatically.

What happens to the conversion

Every conversion linked to the refunded order is set to “rejected.” This is the same status a conversion gets when you reject it manually, but in this case the system handles it for you. A rejected conversion will no longer count toward collaborator performance.

What happens to the obligation

When a conversion is rejected, Siren checks the obligation tied to it. If the obligation has not been paid out yet (its status is anything other than “complete”), Siren automatically sets it to “rejected.” A rejected obligation will not be included in future fulfillments.

If the obligation has already been marked as “complete” (meaning it was included in a fulfillment and a payout record already exists), Siren leaves it alone. Automatically reversing a payout that may have already been sent to a collaborator could create accounting problems, so the system does not do that on its own.

What happens to distribution metrics

If you use revenue-based distributors, Siren also subtracts the refunded transaction value from the current distribution period. This keeps your distribution pool accurate so that future payouts are calculated against the correct revenue totals.

What happens if the payout already went out

When a refund comes in after the obligation has been fulfilled, Siren will still reject the conversion and cancel the transaction, but it will not modify the completed obligation or the payout record. This is by design. At that point, money may have already changed hands, and the right course of action depends on your program’s policies and your relationship with the collaborator.

In this situation, you have a few options:

  • Deduct the amount from the collaborator’s next payout manually.
  • Reach out to the collaborator and arrange a return of the overpayment.
  • Absorb the cost if the amount is small or if your program terms allow it.

Siren does not automate any of these steps because each one involves a judgment call that depends on your specific circumstances.

Partial refunds

Siren currently treats refunds as all-or-nothing at the transaction level. When a commerce plugin signals a refund, Siren reverses the full conversion and obligation tied to that order. There is no built-in mechanism to reduce a commission by a partial amount.

If you issue a partial refund through your commerce plugin and the order status does not change (for example, WooCommerce keeps the order as “completed” after a partial refund), Siren will not fire the refund pipeline at all. The conversion and obligation remain unchanged.

If you need to handle a partial refund, you will need to reject the existing obligation and work out the adjusted amount outside of Siren’s automated pipeline.

Summary of the automatic pipeline

Detect The commerce integration fires the refund event
Cancel The transaction tied to the order is marked cancelled
Reject conversions All conversions tied to the transaction are set to rejected
Reject obligations Linked obligations are rejected unless already completed
Adjust metrics Revenue-based distribution metrics subtract the refunded value

Everything listed above happens without any action on your part.

Timing payouts around your refund window

The simplest way to avoid refund complications is to hold off on creating fulfillments until your refund window has passed. If your store offers a 30-day refund policy, waiting at least 30 days before paying out obligations gives the automatic pipeline time to catch any refunds and reject the affected obligations before you send money.

This is not a requirement, but it is a practical safeguard. If you pay out an obligation and a refund comes in later, recovering that money becomes a manual process between you and the collaborator.

When you need to step in

The only scenario that requires manual attention is when a refund arrives after the obligation has already been fulfilled and paid out. In that case, review the affected payout and decide how to recover the commission based on your program’s terms.

For the technical details of the refund event and the listeners that handle it, see the RefundTriggered event reference.

For developers: This concept maps to the RefundTriggered event. See the events reference for the full pipeline.