When a referred customer converts, you send Scrip an event. Your rules decide what the referrer earns, and the balance stays correct through duplicates, refunds, and churn. You keep your stack. Scrip keeps the books.
Five things, and teams usually discover them one incident at a time. Scrip handles the last four; the first stays in your product.
Your product already knows who referred whom. When the referred account converts, you send Scrip one event for the referrer. A rule you write decides what it earns, and the credit lands on the referrer’s balance. The same event can also reward the referred account.
POST /v1/events { "program_id": "b8a4…", "external_id": "cus_maya", "idempotency_key": "referral-acct_1842-converted", "event_timestamp": "2026-07-08T10:30:00Z", "event_data": { "type": "referral.converted", "referred_account": "acct_1842", "plan": "pro" } }
{
"name": "Referral converted",
"condition": "event.type == \"referral.converted\"",
"actions": [
{
"type": "CREDIT",
"asset_id": "referral-credit…",
"amount": "50"
}
]
}The idempotency_key is a dedupe tag: the same event sent twice counts once. Key it to the referred account and a conversion can never pay twice.
In SaaS the reward usually lands on the bill: a $50 credit on next month’s invoice, a free month at renewal. It goes to the account and has to survive whatever the subscription does next.
Keeping those credits correct through renewals, upgrades, and plan changes is its own page: rewards for subscriptions & SaaS.
The first hundred referrals work fine as a number in a database column. The failures cluster around two events: the same conversion rewarded twice, and a rewarded conversion refunded.
The same conversion arrives twice: a webhook retries, a backfill replays, two services both report the signup. The dedupe key catches it and the reward posts once. Rule budgets cap total payout.
The referred customer refunds in week two, or cancels a month in. In a homegrown system someone subtracts a number and the history is gone. Scrip keeps double-entry books, the method accountants use: taking a reward back is a new entry that cancels the old one, so the balance drops while both stay on record. If the referrer already spent the credit, the balance goes negative and the books show why.
Two parts stay yours. Attribution: your codes, your links, your call on what counts. And the payout: bill credits through your billing system, gift cards through your provider, cash through your payout rail.
Scrip owns everything between: it sets each reward, tracks what every referrer is owed and why, and tells your systems when to pay. Scrip never moves money and never touches your end customer.
Tell us how your referral program works, and we’ll map it to Scrip. Request access for a founder conversation.
If your rewards run through billing, read subscriptions & SaaS next. For why we build this way, read about Scrip.