Scrip
Request access
Use case · Referral programs

Referral program infrastructure on Scrip.

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.

The short answer

What a customer referral program needs to work.

Five things, and teams usually discover them one incident at a time. Scrip handles the last four; the first stays in your product.

  • Attribution. Which customer referred which signup, and what counts as converted. This lives in your product: your codes, your links, your call.
  • Reward rules. What a conversion is worth and when it pays. Say, $20 credit once the friend's first invoice is paid.
  • Balance tracking. What each referrer has earned, spent, and has left, with the history behind every number.
  • Redemption. A balance becomes something real: a bill credit, a gift card, a payout. Fulfillment runs in your stack.
  • Duplicate & fraud handling. One reward per real conversion, caps on what a referrer can earn, and a way to take rewards back when conversions refund.
How it runs

A referral is an event. Treat it like one.

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.

01 · the conversion event
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"
  }
}
02 · the rule that sets the reward
{
  "name": "Referral converted",
  "condition": "event.type == \"referral.converted\"",
  "actions": [
    {
      "type": "CREDIT",
      "asset_id": "referral-credit…",
      "amount": "50"
    }
  ]
}
03 · the ledger postscus_maya balance +$50recorded with full historypays exactly once

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.

SaaS referrals

SaaS referral programs run through billing.

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.

  • 01

    Credits toward the bill

    The referrer earns credit that your billing system applies to a future invoice.$50 off the next invoice when a referred team subscribes.
  • 02

    Tiered referral rewards

    The reward grows as a referrer's conversions stack up.$50 per conversion, $100 from the fifth conversion on.
  • 03

    Two-sided rewards

    Referrer and new account both get something from one conversion.One free month each when the referred team pays its first invoice.
  • 04

    Expiring referral credits

    Credits can expire, so value nobody redeemed comes off the books on schedule.Referral credits expire 12 months after they are earned.

Keeping those credits correct through renewals, upgrades, and plan changes is its own page: rewards for subscriptions & SaaS.

At scale

Where referral rewards break.

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.

Duplicate attribution

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.

Reversals

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.

Where Scrip stops

Scrip computes the reward. You pay it out.

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.

> QUESTIONS

Referral programs, answered.

Create a program and a referral credit asset, write a rule that prices a conversion, and send a referral.converted event from your backend when a referred account converts. The rule credits the referrer's balance on the ledger. Attribution stays in your product: you decide which signup counts as referred, then send the event.
Next

See if Scrip fits your referral program.

Tell us how your referral program works, and we’ll map it to Scrip. Request access for a founder conversation.

Keep reading

If your rewards run through billing, read subscriptions & SaaS next. For why we build this way, read about Scrip.