Campaigns and coupons

We run promotional offers that grant a credit against a customer's bill. One model covers everyone who can hand out a code: direct customers, affiliates, creators, agencies, VCs, and accelerators. This page is how it works. The legal text that governs the offers is the Coupon Terms, published at /offers; when this page and the Coupon Terms disagree, the Coupon Terms win.

The split in one line: Stripe owns the money and the allotment. Our own ledger owns recipe royalty. Earner payouts are manual at first and move to a payout tool only when volume justifies it. No code is ever published: every code is generated, per partner or handed out one at a time.

How it works

1. An offer is a Stripe coupon. Each offer tier is one Stripe coupon with an amount or percent off, a duration (once, repeating for N months, or forever), a redeem-by date, and a first-payment-only flag. Stripe is the source of truth for every live value. Each coupon carries a terms_url of https://www.intempt.com/offers in its Stripe metadata, so the Coupon Terms travel with the coupon wherever it is applied.
2. A code is a Stripe promotion code off that coupon. One coupon backs many promotion codes. The code string is what a customer types at checkout. Each code carries its own max_redemptions (how many times it can be used) and inherits the coupon's first_time_transaction restriction. One coupon, many codes, is how one offer reaches many partners without many coupons.
3. /offers is the Coupon Terms, not a code catalog. /offers is the stable legal Coupon Terms page. We do not hand-publish or auto-list live codes there: a public catalog of codes is both the upkeep nobody does and the coupon/deal-site surface we claw codes back for (see Our rights). No code is published anywhere. Every code is generated and private: a partner's code for their community, or a one-off code a prospect gets by DMing Sid in the Blu Slack community. When a customer applies a code at checkout, checkout shows a "Coupon Terms apply" link to /offers. Never hardcode an offer amount into copy; link to /offers for the terms and let Stripe hold the live numbers.
4. Redemption. A customer redeems a code at Intempt checkout on a new monthly subscription. The credit comes off each eligible monthly invoice during the offer period, which starts the day the code is redeemed.
5. Expiration. After the offer period ends, the subscription continues at the price then in effect. Credits never roll over, never exceed the invoice, and have no cash value.

Allotment: one unique code per partner, a quota on each

Every partner who hands out a code gets their own unique Stripe promotion code, never a shared one. That single decision is what makes allotment and attribution work:

• The quota is max_redemptions on the code. A VC gets a code good for N redemptions; an accelerator cohort gets a code good for its cohort size; a creator gets a code sized to their audience. When the code hits its cap, it stops. That is the allotment lever, and it is native Stripe, no extra system.
• Attribution is the code itself. Because the code is unique to one partner, every redemption of it is unambiguously that partner's. A shared code cannot tell you which VC or which creator drove a signup; a unique code always can. This is also why a leaked unique code is contained and clawable: it burns one partner's quota, not the whole program.
• first_time_transaction enforces first-payment. The coupon restricts redemption to orgs with no prior successful payment, so a code only ever discounts a genuinely new customer. This is enforced by Stripe, not by copy.
• There is no public self-serve code. The open front door is the Blu community: a prospect joins the Blu Slack and DMs Sid for a generated code, or gets one from a partner. Even the public path hands out a generated code one at a time, so nothing is published and nothing leaks to a deal site.

This is the model a marquee partner program runs (a finite pool of codes per partner, claimed one at a time, new-customers-only, deactivated on chargeback) and the discount half of what Stripe already supports natively. We are not inventing a mechanism; we are using max_redemptions as the quota.

Who hands out which code, and what they earn

Two groups, two reasons to hold a code:

• Earners (affiliate, creator, agency, customer referrer) take a cut of the revenue they bring. Their code both discounts the new customer and attributes the referral so we can pay them.
• Distributors (VC, accelerator) pass a benefit to their portfolio and earn nothing. Their code is a bigger discount for their companies, not an income stream.

The agency track

An agency manages marketing for client companies, so it is a reseller, not just a link-sharer. An agency gets a unique reseller code it hands to the clients it onboards, and it earns the same 30% rev-share for 12 months on every client that redeems it. The agency never sees the Coupon Terms it cannot change, and the client, not the agency, is the paying org of record. This is the one actor with no incumbent model to copy, so it is defined here rather than borrowed.

Attribution and payout rails

The discount and the payout are two separate rails, and keeping them separate is deliberate.

• The discount rides Stripe. The promotion code applies the credit and records, in Stripe, which code (and so which partner) was redeemed. Stripe is the billing truth.
• The referral payout is manual first, a tool later. The Stripe code already records which partner drove each redemption, so attribution is free. For v1 we pay the few early earners their 30% by hand (a Stripe Connect transfer, or hold until they have earned enough). When the number of earning partners makes manual payout and 1099s a chore, we add a payout tool (Dub, Rewardful, FirstPromoter, or similar) for automated attribution, Stripe Connect payouts, and tax. We take no such dependency for v1.
• Recipe royalty rides our own ledger. The 20% a creator earns on credits their published recipes burn in other orgs is usage-metered, which no payout tool does. It stays on Intempt's own ledger and settles into the same creator payout.

Whatever payout tool we add later, the code is always a Stripe promotion code. Stripe remains the only place a discount is actually applied.

Eligibility and limits

• First-payment orgs only. Every offer is for organizations making their first payment to Intempt, on a new monthly subscription bought at Intempt checkout. Not for existing or former paying customers.
• One offer per org. An organization redeems one code in total. Codes do not stack with each other or with any other discount or negotiated pricing. Spinning up extra orgs to redeem again is not allowed.
• What a credit covers. Plan seats, AI Pass, and usage charges on the monthly invoice. It does not cover credit top-ups, auto-reload, usage prepay commitments, Shopify-billed plans, or Order Form services.
• A global budget cap governs the program as a whole; see the Coupon Terms for the live figure.

When a campaign customer wants an annual contract

A redeemed credit keeps applying to eligible monthly invoices through plan, seat, and AI Pass changes. Switching to annual billing ends the offer (Coupon Terms 4.2): annual is not a monthly invoice, so there is nothing for the monthly credit to reduce.

We do not extend, swap, or cancel a redeemed offer to win a deal. A change to an offer never reduces a credit an org has already redeemed. When a monthly campaign customer converts to annual, the sales motion sizes the annual contract on its own merits, knowing the monthly credit stops at conversion.

Our rights

• We can change, suspend, or end any offer, or stop new redemptions, at any time. That never reduces a credit already redeemed.
• We can refuse a redemption, and claw back credits, where a code was obtained or used through fraud, duplicate accounts, or by listing it on a coupon or deal site. A unique code makes this precise: we revoke the one partner's code, not the whole offer.

Creating a campaign or onboarding a partner

1. Tier coupon, once. Create the Stripe coupon for the offer tier with the amount/percent, duration, redeem-by, and first_time_transaction on, and set its terms_url metadata to https://www.intempt.com/offers.
2. Mint one code per partner. For each partner, create a Stripe promotion code off that coupon with a max_redemptions equal to their agreed allotment. Do not reuse a code across partners.
3. Track the earner. For an affiliate, creator, or agency, record the partner and their code; the code already attributes every redemption. Pay their 30% by hand until a payout tool is added.
4. Publish no codes. Nothing goes on /offers but the Coupon Terms, and no code is named in marketing copy. A prospect with no partner gets a code by DMing Sid in the Blu Slack. If the offer needs new Coupon Terms language (a new audience or exclusion), update the Coupon Terms on /offers before any code goes live.

Related: channels-overview · who-we-build-for · influencers · creator-operations · startup-programs.