Pay in Product, Not Cash
Reward both sides in something that costs you cents, not dollars.
Dropbox gave you 500MB of free storage for referring a friend, and gave your friend the same 500MB back. That storage cost Dropbox a few cents in disk space and was worth something real to a user who was one large file away from a full drive. Dropbox had grown slowly for a long stretch before it shipped that exact mechanic, then rode it from roughly 100,000 users to 4 million in about 15 months. PayPal ran the one legitimate exception: paying $10 cash to both sides worked because every referral triggered a funded transaction PayPal took a cut of, so the reward paid for itself out of real revenue. Copy Dropbox's model. Copy PayPal's cash number only if you also have PayPal's transaction economics, and almost nobody does.
What to do: Reward both the referrer and the invitee with a unit of your own product, storage, credits, seats, generations, something that costs you a fraction of a cent and reads as real value to the user. Fire the reward the moment the referral converts into a real paying or activated user, not when someone merely clicks "invite a friend." Meter the reward in whatever currency your product already tracks, so it is one more row in a usage table, not a new payments flow you have to build and reconcile.
Why it works: The reward feels real to the user because it is priced in the thing they already want more of from you, while it costs you next to nothing because you already have the marginal capacity sitting idle.
Example: Kling AI's live referral program pays the referrer 200 credits for every friend who buys their first individual plan, and gives that friend a 10 percent credit bonus of their own, capped at 1,500 credits. Same Dropbox math, ported to a usage-based AI product: a credit costs Kling compute, not cash, and the reward only fires after a real purchase.
Walk it through
I opened Kling AI's referral program in July 2026. Here is exactly what it showed.
1. Open the program page. It sells itself before you sign in.
https://app.klingai.com/global/invitation

The whole offer is readable without an account. Invite a friend to buy an individual plan for the first time and earn 200 credits. The friend gets a 10 percent bonus on top of their own credits, capped at 1,500. No cash changes hands anywhere in this loop, only a unit the product already prices.
2. Check the eligibility rule. It is the fraud gate.
The page states it plainly: the friend has to be a first-time individual-plan buyer, and 7-day trials do not count. That one rule closes the obvious loophole of two accounts trading free trials back and forth to farm credits.
3. Price the reward against the retail rate card.

The Standard plan sells credits at "as low as $1.33 per 100 Credits." At that rate, the 200 credits Kling hands the referrer reads as roughly $2.66 of value to the user. What it costs Kling is a slice of compute at internal cost, not $2.66 in cash. That gap, retail-priced to the user, near-zero to the company, is the entire trick, and it is the same gap that made Dropbox's gigabytes cheap to give away.
The read
- The trigger is the purchase, not the invite. Kling only pays out after the friend buys a plan, exactly like Dropbox waited for a real signup, not a raw click on "invite a friend." Reward the outcome you actually want repeated.
- The unit is whatever you already meter. Storage for a cloud company, credits for a generation product, seats for a collaboration tool. Pick the currency your product already tracks and the accounting takes care of itself.
- The cap is the fraud control. 1,500 credits, 16GB of storage, whatever ceiling you set is what keeps the loop from turning into a farm. No cap is an invitation to be gamed.
Steal it
Pick the unit your product already produces cheaply and your users already want more of. A CRM gives extra contact rows, a video tool gives extra render minutes, a scheduling tool gives extra team seats. Trigger the reward the instant the referred user does the thing that makes them a real customer, not when they click the invite button, and pay the same reward to both sides so neither person feels like they did the other a favor. That symmetry is most of why Dropbox's version outgrew every one-sided referral program that came before it.
Defend the mechanic the way Kling defends it. Gate the reward behind a genuine paid action, not a signup, and refuse to pay out on trials or free tiers that already cost you real money to serve. If your product runs on token or compute cost the way most 2026 AI tools do, work out what the reward actually costs you at the unit level before you launch it, the same way Dropbox knew a gigabyte of storage cost pennies before it gave away hundreds of them. If you cannot say that number out loud, you are not ready to turn the loop on.
Gotchas
- This only stays cheap if your marginal cost is actually near zero. If serving one more unit of your product costs you real money, this is not "cheap," it is a discount you cannot afford, and the loop bleeds cash the way a cash referral would without PayPal's transaction fee funding it.
- Free-tier abuse is the same fraud vector cash referrals had. Farming trial accounts to trigger fake conversions is the modern version of the fake sign-up bots PayPal fought. Gate the reward behind a real paid action the way Kling does, and verify the referred account before crediting.
- A published cap reads as trust, an open-ended reward reads as a bug waiting to be found. Decide the ceiling before launch, state it on the page the way Kling states its 1,500-credit cap, and do not quietly tighten it after people have already started sharing.