Affiliate fraud prevention for small SaaS programs

Most affiliate fraud prevention advice is written for ecommerce at scale. It talks about device graphs, coupon extensions, browser fingerprinting, and fraud rings.

Small SaaS programs have a different problem. You do not need a surveillance machine on day one. You need enough rules to stop obvious abuse without punishing legitimate creators.

For dev tools and indie SaaS, the practical risks are self-referrals, coupon leakage, refund harvesting, duplicate customer attribution, and conversions that happen too fast to be real influence. Each one has a clean prevention pattern if you design it before launch.

Fraud rule number one: write the rules down

A fraud rule that lives only in the founder's head will eventually create a fight.

Your affiliate terms should say, in plain language, what is not allowed:

• referring yourself or your own company
• using your link for customers who already planned to buy through another channel
• publishing private coupon codes
• bidding on branded search terms if you do not allow it
• creating fake accounts or test purchases for commission
• encouraging refunds after commission is credited

This is not about sounding legalistic. It is about making enforcement boring. When a commission is rejected, you can point to the rule and the event trail.

Self-referrals

Self-referrals are the most common abuse case in small SaaS programs. Someone joins the affiliate program, clicks their own link, buys the product, and expects a discount in the form of commission.

The prevention rule is simple: compare the affiliate identity to the customer identity.

At minimum, block or flag when:

• affiliate email equals customer email
• affiliate domain equals customer domain
• payout email equals customer email
• the same person owns both accounts

The Ambassly spec makes this an MVP fraud guard: if referral email or customer email matches the affiliate email, auto-reject the commission and write an audit event.

Do not silently delete the commission. Mark it rejected and explain why. Silent changes create distrust even when you are right.

Duplicate customer guard

A subscription customer should not be referred twice.

The clean rule is one referral per Stripe customer ID. When a customer first maps to a referral, store that relationship. Later invoices from that customer can create recurring commissions for the same affiliate if your program allows it, but a second affiliate should not overwrite the original referral just because the customer clicked a new link later.

There are exceptions. You may choose last-click attribution for leads that have not converted yet. You may let a referral expire after a cookie window. But once a paying customer is attached to an affiliate, treat that as a durable record unless a human explicitly changes it.

This prevents commission fights where two creators both claim the same account after the customer watched multiple videos.

Coupon leakage

Coupon leakage happens when a private affiliate code escapes into coupon sites, deal forums, browser extensions, or posts that were not part of the program.

For SaaS, the damage is not just margin. It breaks attribution. A customer who already planned to buy searches for a discount, finds a leaked affiliate coupon, and now the wrong partner gets paid for demand they did not create.

The prevention pattern:

• give affiliates links first, coupons second
• make coupon codes affiliate-specific when possible
• keep private codes off public pages
• monitor redemptions by coupon and referrer
• reject commissions where the coupon source violates terms
• rotate or disable leaked codes quickly

Do not overreact to every coupon mention. Some creators legitimately publish codes as part of a review. The issue is whether the code appears in places that do not belong to the affiliate and do not create new demand.

Refund harvesting

Refund harvesting is the ugly pattern where a referred customer buys, the affiliate gets credited, and the customer refunds after the commission is approved or paid.

You prevent most of it with two boring controls.

First, set a hold period at least as long as your refund window. If you offer 30-day refunds, do not pay commissions after 14 days. Wait until the refund risk is mostly known.

Second, listen for refunds and claw back the commission. In a Stripe-based program, charge.refunded is one of the events that matters. If the commission is pending or approved, move it to a clawed-back state. If it was already paid, create a negative adjustment against a future payout.

Refunds are not always fraud. Customers refund for normal reasons. The system should handle refunds as a ledger event, not as a moral accusation.

Suspiciously fast conversions

The Ambassly spec calls for flagging conversions that happen less than 60 seconds after the click. That is a good lightweight heuristic.

A fast conversion is not proof of fraud. A buyer may click a creator's link at the last second before checkout. But a pattern of instant clicks and purchases can indicate self-referrals, coupon poaching, or last-minute attribution capture.

Treat this as a review flag, not an automatic rejection.

Useful fields to store:

• click timestamp
• conversion timestamp
• time from click to conversion
• affiliate ID
• link ID
• customer ID
• referrer

You do not need to build a scoring engine. A simple "converted in 22 seconds" note in the commission audit trail is enough for early programs.

Link-level monitoring

Per-content links are not just useful for creators. They also help fraud prevention.

If an affiliate has one link for a YouTube tutorial, one for a newsletter, and one for a course module, you can see which source produced the conversion. If a link labeled "private course" suddenly drives hundreds of anonymous coupon-site clicks, something is off.

This is much harder when every affiliate gets one generic link. Generic links collapse context. Per-content links preserve it.

Manual review is not a failure

Founders sometimes treat manual approval as unsophisticated. For a young affiliate program, it is usually the right choice.

Manual review lets you see patterns before you automate:

• one affiliate with many refunds
• many customers using the same coupon but no matching content traffic
• repeated self-referral attempts
• conversions seconds after clicks
• the same customer appearing under multiple affiliates

Once the patterns are boring, automate more of the approval flow. Until then, the review queue is how you learn what your program actually attracts.

Do not punish good affiliates with opaque rules

Fraud prevention can damage trust if affiliates cannot see what happened.

A creator should be able to see that a commission was pending, then rejected because the customer email matched the affiliate email. Or that a commission was approved, then clawed back because the Stripe charge was refunded. The language can be neutral, but the reason should be visible.

That is why an append-only commission event log matters. It protects the company from abuse and protects the affiliate from unexplained changes.

A practical starter policy

For a small SaaS program, start with this:

• 60-day cookie window
• 30 to 45 day hold period
• one referral per Stripe customer
• self-referrals auto-rejected
• conversions under 60 seconds flagged
• leaked coupon commissions reviewed
• refunds claw back unpaid commissions
• paid refunds create negative adjustments
• every status change writes an audit event

That is enough to launch without pretending you are an enterprise fraud platform. The goal is not to catch every theoretical bad actor. The goal is to make abuse unrewarding, make normal refunds routine, and make every commission explainable.