Launch notes: tracking, ledger and payouts are live

The first production version of RelayWonder is running, and it is built around one idea: SaaS affiliate tracking is only trustworthy when every commission can be traced back to a specific Stripe invoice, every correction is a visible row rather than an edit, and the money moves from the brand to the partner without ever passing through us. This post is the long version of the release notes. It walks through what shipped, how each piece behaves with real numbers, and what is still missing, so that a brand deciding whether to move its program this month has enough detail to decide.

What is in the first version

Six things are live today. Each one is small on its own; together they are the whole loop from a partner sharing a link to a partner receiving money.

• Tracking script and click endpoint that set a first-party cookie on your domain, plus personal coupon codes created in your Stripe account when a partner is approved.
• Stripe webhooks for invoice.paid, refunds and disputes that write to an append-only ledger, with a hold period and a minimum payout configured per program.
• Payout batches: open a batch, review the rows, export a PayPal or Wise mass-payout file, pay from your own account, mark the batch paid. Balances are kept per currency.
• Partner portal: links, codes, balance, statements, monthly CSV downloads and tax form upload (W-9 or W-8BEN, uploaded once).
• Brand console: programs, partners, applications, ledger, reports and team members with roles.
• Public program pages and a marketplace where a partner applies to any brand with the single account they already have.

How SaaS affiliate tracking works here

Most affiliate tools attribute a sale at the moment of checkout and then stop. For a subscription business that is the wrong moment. The first payment is often the smallest one, trials convert later, plans change, and renewals are where most of the revenue sits. So we attribute at the invoice level, which means we look at every invoice Stripe finalises and ask whether it belongs to a referred customer.

Three signals can connect a customer to a partner. They are checked in this order and the first match wins:

1. A personal coupon code. When you approve a partner, we create a promotion code in your Stripe account that only they share. If the code is applied at checkout, the customer is attributed to that partner with no click and no cookie involved. This catches podcast mentions, printed material and anything else where nobody clicks a link.
2. A first-party cookie. The tracking script runs on your domain, so the cookie is set by your site, not by a third-party domain that browsers increasingly block. The default window is 60 days and you can change it per program. At signup we pass the stored partner reference into the Stripe customer metadata.
3. Customer metadata already present in Stripe. If you migrated from another tool and your customers carry a referral field, we read it so that renewals keep paying the partner who originally earned them.

Once a customer is linked, every invoice.paid event for that customer produces a commission row [1]. First payment, every renewal, upgrades and add-ons are all invoices, so they are all covered without special cases. Refunds and disputes arrive as their own webhook events [2] and produce negative rows against the same partner, which is the part most brands get wrong when they run attribution by hand.

The append-only commission ledger

The ledger is a list of rows that only grows. Nothing is updated in place and nothing is deleted. If a commission turns out to be wrong, a correcting row is added that references the original. If a refund comes in six weeks after the sale, a negative row is added dated the day the refund happened. The balance a partner sees is simply the sum of their rows in a given currency, minus whatever is still inside the hold period, minus whatever has already been paid.

This matters for three reasons. First, disputes between a brand and a partner become a reading exercise instead of an argument: both sides see the same rows with the same Stripe invoice IDs. Second, accountants can reconcile a month without asking anyone what changed. Third, our own bugs cannot silently rewrite history; the worst case is a wrong row that we fix with another row, and both stay visible.

A worked month with real arithmetic

Take a program paying 25% recurring commission with the default 60-day cookie, 30-day hold and $50 minimum payout. A partner named Dana shares a link on 3 June. Here is what her ledger looks like by the end of August.

• 5 June: customer A signs up on the $80/month plan through the cookie. Invoice paid, row of +$20.00, payable from 5 July.
• 12 June: customer B uses Dana's coupon code on the $200/month plan with a 10% first-month discount. The invoice is $180, so the row is +$45.00, payable from 12 July. The commission is on what was actually invoiced, not the list price.
• 5 July: customer A renews. Row of +$20.00, payable from 4 August.
• 12 July: customer B renews at the full $200. Row of +$50.00, payable from 11 August.
• 20 July: customer A asks for a refund of the July invoice. Row of -$20.00, dated 20 July, applied immediately.
• 5 August and 12 August: both renew again. Rows of +$20.00 and +$50.00, payable in September.

When you open the August payout batch on 1 September, the rows that are both past their hold and not yet paid are the June and July commissions: 20 + 45 + 20 + 50 = $135.00, less the July refund of $20.00, which gives $115.00. The August renewals of $70.00 are still inside the hold and appear in the batch as pending. Dana clears the $50 minimum, so she is included. A partner with $38 payable would be carried over to the next month, and the portal tells them so instead of showing a zero.

Notice that the refund did not require anyone to remember customer A. The Stripe event arrived, the negative row was written against Dana because customer A is attributed to her, and the batch computed itself. That is the whole argument for invoice-level SaaS affiliate tracking: the hard cases are the ones nobody has time to handle by hand.

Payout batches: we compute, you pay

RelayWonder never holds money. A payout batch is a document, not a transfer. The procedure is:

1. Open the batch for the month. Every partner with payable rows above the minimum in a given currency gets one line; partners below the minimum are listed separately as carried over.
2. Review. Fraud flags from the self-referral, click-burst and same-user-agent checks are shown next to the affected lines, and a flagged line is held out of the export until someone on your team clears it.
3. Export. We produce a CSV in the exact format PayPal Payouts expects [3] or the format Wise batch payments accepts [4]. Partners choose their payout method and enter their own details in the portal; you never retype them.
4. Pay from your own PayPal or Wise business account. The money goes directly from you to the partner.
5. Mark the batch paid. Each line gets a paid row in the ledger with the date, and partner balances drop accordingly. Statements for the month are generated for every partner included.

Because the batch is per currency, a brand charging in USD and EUR gets two files, and a partner who earns in both sees two balances. We do not convert, because converting would mean choosing a rate, and choosing a rate is a decision that belongs to whoever is actually paying.

Partner portal and brand console

A partner has one account for every brand on RelayWonder. Inside it they see each program they belong to, their links and personal codes, a balance per currency, the hold status of recent rows, monthly statements and a CSV export of every row for their own bookkeeping. Tax forms are uploaded once: a W-9 for US persons or a W-8BEN for everyone else [5][6]. Our operators verify the upload and every brand paying that partner sees a verified status without seeing the form itself. Issuing a 1099 at year end remains the paying business's responsibility, and the statements give you the totals you need for it [7].

The brand console is where SaaS affiliate tracking becomes something you can actually run. It has the program settings (rate, cookie window, hold period, minimum payout, currency), the partner list with application review, the full ledger with filters, reports by partner and by month, and team members with roles so that the person who reviews fraud flags does not have to be the person who exports the payout file.

What is not in it yet

We would rather tell you now than have you discover it on a Tuesday afternoon. The following are not available in this version. Each one has a place in the product with a plain label explaining what is pending.

• Open-web Hunter search. Finding partners across the open web depends on search sources we have not connected. Today you can search partners who are already in the network.
• Sending mail from inside the product. Outreach drafts are generated and you copy them into your own mailbox. Nothing is sent from our domain.
• AI drafting and scoring of partners or content. The fields exist; the models are not wired in.
• Shopify. Tracking is Stripe-only for now. If your checkout is not Stripe, the invoice attribution described above will not run.

We also do not show any number we do not have. There are no demo partners, no placeholder notifications and no estimated figures anywhere in production.

Moving an existing program

If you are coming from Rewardful, FirstPromoter or a spreadsheet, moving your SaaS affiliate tracking over is three steps. Import your partners by CSV (email, name, payout method); each one receives an invitation to claim or link their RelayWonder account. Map your customers: if your Stripe customers already carry a referral identifier in metadata, we read it, and renewals continue to credit the right partner from the first invoice after you connect. Set the program terms to match what you promised, including any legacy partners on a different rate, and run one payout batch in parallel with your old tool before switching off the old one. The first version is free up to $1,000 of partner-driven revenue per month, then $49 up to $10,000 and $129 up to $50,000, with no percentage taken on any plan, so the parallel month costs nothing for most programs.