Usage-based pricing changes the shape of an affiliate payout without changing the shape of the affiliate link. The click, the signup, and the subscription id behave the same way. What changes is the number: a customer who pays $18 in month one can pay $900 in month six, and the same rate applied to both invoices produces two very different commissions.
Most programs get this wrong, because the tools assume fixed prices while the pricing model produces variable ones. The result: programs that underpay on spikes, pay commission on tax, or lose the affiliate at the first $0 invoice. Here is how the money flows on a metered bill, and the decisions worth making in writing.
TL;DR
- The invoice is the unit of pay. A percentage rate on a metered plan produces a different amount every period, because the bill is different every period.
- Commission belongs on the pre-tax amount the provider reports as paid: Polar's net amount, Paddle's subtotal. Tax was never your revenue.
- A $0 first invoice is a referral, not a conversion. Store the affiliate against the subscription, then pay on the first invoice that clears.
- Credits and proration can shrink a later invoice or push it negative. Decide in writing how you treat a negative period.
- Show affiliates why the number moved. A payout that swings 10x with no explanation reads like a broken dashboard.
Why a variable bill breaks the usual commission math
A fixed-price program has one number to argue about: the customer signs up at $49/mo, the affiliate earns a set amount every period, and forecasting is trivial.
A metered plan has no such number. A customer billed per API call or per gigabyte might pay $9 in a short first period, $260 in month two, $3,400 in the month they wire you into production, then $150 after they optimize their calls. A 30 percent rate on those invoices produces four unrelated commissions, and neither you nor the affiliate controls the biggest one. The customer's engineering decisions do.
Three consequences follow. Forecasting becomes a range, so an affiliate planning on a monthly figure will mis-plan. The first period usually lies, because it is prorated, small, or zero. And a rate that felt cheap on a $49 plan is expensive on a spike: one $3,400 invoice at 30 percent is over a thousand dollars of commission.
None of that argues for abandoning percentages, only for knowing which model you run: a percentage follows the bill, a flat amount ignores it. Recurring vs One-Time Commissions works through the fixed-price version of that choice.
How a variable bill becomes a commission
Every affiliate platform does the same three things: it receives an event when money moves, it reads the amount out of that event, and it multiplies. The differences live in step two, because providers disagree about which number represents what you were paid.
| Provider | Event that carries a usage renewal | Amount field used | What metered billing changes |
|---|---|---|---|
| Polar | order.paid | net_amount, pre-tax and after discount | Metered usage lands on the invoice at the end of the cycle, so one order covers one period |
| Stripe | invoice.payment_succeeded | amount_paid, on cycle invoices only | Usage invoices arrive on the normal interval; anything else is skipped rather than guessed at |
| Paddle | transaction.completed | details.totals.subtotal, a pre-tax minor-unit string | Each period is its own transaction, and payloads carry no customer email |
| Any other provider | Your signed webhook | Whatever amount you put in the payload | You own the shape, so send the pre-tax amount plus the subscription id |
| Fixed-price plans | The same events | The same fields | One code path for every price model, which is the point |
Sled floors the arithmetic to the cent rather than rounding up, so a commission is never larger than the amount that supported it. The normalizer also ignores the price object entirely, so a tiered, seat-based, or metered order is read exactly like a flat $49 order. That decision has a story behind it, and The Bug That Wasn't a Bug tells it better than a spec would.
The practical consequence: your tracking layer should not care how an invoice was assembled, only that it was paid, what the pre-tax total was, and which subscription it belongs to. Setup for Polar.sh, Stripe, and Paddle is worth reading before you wire anything up.
The commission base: pre-tax, post-discount, post-credit
Three adjustments decide whether the number you multiply is money you actually kept.
Tax is not yours. Polar and Paddle are merchants of record, so the invoice total can include VAT or sales tax that never reaches your bank account. Commission on a tax-inclusive total overpays on every taxed sale, which is why Polar's net amount and Paddle's subtotal are the right fields and grand totals are the wrong one.
Discounts are not yours either, and on usage plans they hit twice. When a subscription carries a discount, providers apply it to the whole invoice, metered usage included. A 20 percent discount therefore cuts the commission base and the commission you owe by the same proportion. If you stack a launch discount on a usage plan, run the arithmetic before announcing a rate: 30 percent of a discounted, taxed invoice is meaningfully less than 30 percent of list price, and less still after payment fees.
Credits are a policy question, not a field. A credit balance applied against a future invoice reduces what that period collects, and whether it earns commission is your call. Either answer is defensible; deciding in month seven, when an affiliate asks why a real invoice paid out nothing, is not.
Write all three into your terms in one paragraph. It is boring, it prevents the most common disputes on a metered plan, and it takes ten minutes.
Attribution when the first invoice is $0
Usage-based plans are unusually good at producing a first period with no money in it: a trial, a free tier with metering attached, a prorated signup on the last day of a cycle, or a credit-covered month all create an invoice that reports nothing payable.
The mechanic that keeps the referral alive is storing it against the subscription rather than the order. When a $0 event arrives with both a referral code and a subscription id, record the pair, pay nothing yet, and let the first real charge inherit the affiliate from that mapping. Renewals then inherit from the subscription for as long as it lives, which is how a metered plan keeps crediting the original affiliate on invoices that carry no checkout metadata.
That path has one honest gap. Providers do not all attach an identifiable reference to the $0 event, and where a $0 event is ignored with no stored referral, the first paid cycle has nothing to inherit from and that payment goes uncredited. Stripe is the case to test rather than assume: run a free-trial subscription on a metered price to its first paid cycle in test mode, confirm a conversion appears, and check whose name is on it. That is cheaper than explaining a missing commission to your best affiliate in month six.
Two defaults are worth knowing while you test: Sled ships with a 30 percent commission, a 90 day cookie, and a $20.00 minimum payout, all editable, plus a per-affiliate rate override.
Renewals that never repeat: overage, seats, and prepaid credits
Four shapes of usage billing produce four payment rhythms, and affiliates notice all of them.
Metered with a base fee. The customer pays a base each period plus usage on top, so commissions start small and grow with adoption. This is the friendliest shape for an affiliate, because effort converts into a rising number.
Overage past an included allowance. Usage above the allowance gets billed, sometimes immediately once the account crosses a monetary threshold rather than at the end of the period. The affiliate sees two commissions in one month and none the next, which looks erratic until you explain it.
Per-seat or per-workspace pricing. Seats change mid-period, so providers prorate: an added seat bills from the change date, a removed seat becomes a credit on the next invoice. That commission comes in lower than the seat count suggests.
Prepaid credits and annual commits. The customer pays a lump sum up front and consumes it over months, so your tracking sees one payment, a percentage rate pays one commission, and the affiliate gets a large payout followed by eleven quiet months. Making commission follow consumption instead is a revenue recognition decision, and it belongs in your terms.
Caps, thresholds, and the rate you can afford
Usage-based products usually ship with something that limits the customer's downside, and those mechanisms also limit the variance in your commissions.
Metered prices commonly carry a cap: once usage exceeds it, the customer pays the cap amount. A cap helps forecasting, since a capped customer cannot produce a five figure invoice, which makes a percentage a bounded commitment. If spike risk is what worries you, cap the price rather than cutting the rate later: affiliates read a cap as fair and a mid-year rate cut as a bait and switch.
Billing thresholds work the other way. When an account is invoiced the moment accrued usage crosses a monetary amount, one busy week can generate an invoice that a normal cycle would have bundled into month end. Each invoice is a payment, so each is a commission, and the affiliate's count of conversions jumps while the total barely moves. A rule that treats only the standard cycle as a renewal needs an explicit decision about those invoices.
Rate designs that survive a bill that swings
Rate design on a metered product is about who absorbs variance, you or the affiliate.
| Design | How it pays out | Good fit when | The catch |
|---|---|---|---|
| Flat percentage on every paid invoice | Percentage of each pre-tax amount, for the life of the subscription | Usage grows over the relationship and you want retention alignment | Payouts are as volatile as the bill |
| Same percentage, lower first-year rate | Same mechanic, different number in year one | You want to reward retention more than spikes | Affiliates dislike watching a rate fall, so the reason must be visible up front |
| Higher rate on the base fee, standard rate on usage | Pay generously on the predictable part of the invoice | You sell a platform fee plus metered usage | You compute two numbers per invoice, and the tracker will not |
| Per-affiliate rate override | A different percentage for a named affiliate | Top performers and negotiated deals | Nothing, as long as the override is documented |
| Flat bounty per activated customer | A fixed amount per qualified signup | Churn is high and usage is unpredictable | A percentage engine will not compute it, and volume chasers arrive first |
If you are unsure, keep the flat percentage and fix the variance elsewhere: cap the price, extend the cookie window, or lower the rate slightly. Any of those is easier to explain than a rate that changes by month.
Refunds, credits, and chargebacks on a variable bill
Corrections are more likely on a variable bill, because a big invoice is easier to dispute than a $49 charge.
Refunds reference the original payment, and providers do it differently: a Stripe refund may point at a payment intent, an invoice, or a charge, so the lookup has to try every id it is given. When a refund arrives before the original order event, which happens because providers do not guarantee delivery order, record the refund as a tombstone and create the later conversion already marked refunded, so a refunded sale never becomes payable.
Chargebacks are not refunds. Paddle reports both as adjustments, distinguished by an action field, and they count only once the adjustment reaches an approved status, since a pending cancellation is not a reversal yet. Counting pending adjustments as reversals produces a balance that jumps around and an affiliate who stops trusting the dashboard. When the Refund Beats the Sale covers the sequencing bug behind most of these failures.
Then decide what happens to money already paid out. Reversing a commission before payout lowers a balance, which nobody minds. Reversing it after payout creates a negative balance and needs a written rule: offset against future commissions, or absorb it up to a limit.
One thing should never happen: clawing back commission on invoices that already cleared. A cancellation ends future renewals because the provider stops sending payment events. It does not un-earn periods the customer already paid for.
Payout minimums against a small average invoice
A payout floor that works on a $49 plan can fail badly on a metered one. Take the default $20.00 minimum, a 30 percent rate, and an average referred invoice of $6.00: the commission is $1.80 per period, so one customer needs about eleven billing periods to push an affiliate past the floor. Three customers bring that down to roughly four months. The floor is not wrong, but it interacts with your average invoice in a way nobody notices until an affiliate asks where their money is.
Three fixes, in order of preference. Batch payouts on a schedule so small balances accumulate visibly and land together. Lower the floor if your rail makes that cheap, and accept the fee on small amounts. Or raise the rate on the first period, which clears the floor quickly and costs you only the smallest invoice of the relationship.
Whatever you choose, the balance below the floor has to stay visible and never quietly expire. Affiliates also need a rail they can receive on: Sled supports PayPal, Wise, Payoneer, Revolut, bank transfer, and crypto, the merchant chooses which are enabled, and each method stores its own details. Conversions export as CSV by date range, which turns a month of metered invoices into a ledger a bookkeeper will accept.
What a usage-based affiliate dashboard has to show
On a fixed-price plan, an affiliate dashboard is a scoreboard. On a metered plan it has to be an explanation, because the number moves for reasons the affiliate cannot see.
| Field | Why it matters on a metered plan |
|---|---|
| Each conversion with its invoice amount and commission | Lets the affiliate connect a swing to a specific customer and period |
| Whether a row is a first period or a renewal | Shows whether growth comes from new customers or from existing ones using more |
| Refunded and reversed entries, clearly marked | Stops a correction from looking like a lost commission |
| Pending balance versus paid total | Shows what the payout floor is holding back |
| Export of the raw rows | Trust comes from checking your arithmetic, not from a chart |
The rule of thumb: any number an affiliate can question should be one click from the row that produced it. Usage-based programs lose affiliates to ambiguity more often than to competitor rates.
FAQ
How do you pay affiliate commission on usage-based pricing? As a percentage of each invoice that clears. The tracking layer reads the payment event from Polar, Stripe, or Paddle, takes the pre-tax amount, multiplies by the rate, and stores one conversion per invoice. Renewals inherit the affiliate from the subscription id, so a metered customer keeps paying their original referrer for as long as the subscription runs.
Do $0 invoices and trials count as affiliate conversions? They count as referrals, not conversions. Record the affiliate against the subscription id when the $0 event arrives, pay nothing that period, and let the first paid charge inherit from that mapping. Since providers do not all attach identifiable references to $0 events, verify the path in test mode before promising recurring commissions on trials.
What happens when a customer buys prepaid credits or prepays annually? Your tracking sees one payment, so a percentage rate pays one commission on the full amount: simple and immediate, with a large payout in one month and nothing in the months after it. If you would rather pay as credits are consumed, that is a revenue recognition decision and belongs in your published terms.
Should the commission rate be lower on a usage-based product? Not automatically. A lower rate mainly protects you against spikes, and a price cap does that more precisely. The stronger reasons to change it are mix (enterprise usage is worth less per point of affiliate effort than many small accounts) and your tolerance for variance. Cap the price or split the base fee from the metered part before cutting the number an affiliate sees.
Running a usage-based product on Polar, Stripe, or Paddle? Sled tracks every paid invoice, inherits renewals from the subscription id, blocks self-referrals, and pays out in six currencies for a flat $19/mo with no cut of your commissions. Start free trial, and read Affiliate Programs for Developer Tools next.