Why we will never hold partner money

Partner payouts work one of two ways. Either the platform collects money from the brand, holds it, and pays partners on its own schedule, or the platform computes what is owed and the brand pays partners directly from its own PayPal or Wise account. RelayWonder does the second and will never do the first. A platform that holds money becomes a payment business: it needs money-transmitter licensing or a bank willing to carry that risk, it sits on float that belongs to someone else, it adds a second settlement cycle between the brand and the partner, and it stacks its own fees on top of the payout fees. For any program under a few million dollars a year, a monthly CSV that the brand reviews and approves is faster, cheaper and safer than a platform wallet. This post explains the arithmetic behind that claim, walks through one month of payouts end to end, and is honest about what the brand gives up in exchange.

Two ways to run partner payouts

Call the first model the wallet model. The brand tops up a balance on the platform, or the platform charges the brand's card for the month's commissions plus a fee. The platform then pays each partner, usually to PayPal or a bank account, on a date the platform chooses. From the brand's point of view this is one bill a month. From the partner's point of view, the money comes from a company they never signed up with.

Call the second model the ledger model. The platform keeps an append-only ledger of every commission, refund and adjustment, applies the hold period and the minimum payout, and at the end of the month produces a batch: a list of partners, amounts, currencies and payout addresses. The brand downloads that batch as a PayPal Payouts or Wise batch-payment CSV, uploads it to its own account, approves it, and marks the batch as paid. The platform never touches a dollar.

Most affiliate software for SaaS uses the ledger model. Rewardful exports a PayPal or Wise payout CSV and does not take a cut, and FirstPromoter exports for PayPal mass payouts (both as checked on 2026-09-18). PartnerStack, which targets larger B2B programs, manages payouts on the platform side and prices by quote (as checked on 2026-09-26). The wallet model is not wrong for a marketplace with tens of thousands of partners and a compliance team. It is wrong as a default for a brand with forty partners and one person running the program.

What holding money turns a platform into

The moment a platform accepts money from one party with the promise of delivering it to another, it is transmitting money. In the United States that is the definition of a money services business under FinCEN rules, with federal registration and, in most states, a state money-transmitter licence each [1]. The alternative is to run the flow through a licensed partner such as a Stripe Connect platform account, where the licensed entity carries the regulatory burden and charges for it [2]. Either way the cost exists and is passed on to the brand in the platform fee, the payout fee, or the FX margin.

Licensing is the visible cost. The quieter costs are these:

• Float. Between the day the brand pays the platform and the day the partner receives the money, the platform holds the funds. Some platforms earn interest on that float. All of them are a counterparty risk for the brand: if the platform fails, the brand has paid and the partner has not been paid, and the brand still owes the partner under its own program terms.
• Two settlement cycles. The partner waits for the brand to pay the platform, then for the platform to run its payout cycle. A brand on a thirty-day hold that pays its platform on the 5th and a platform that pays partners on the 15th has turned a thirty-day hold into a forty-five-day wait.
• Stacked fees. A platform fee, then the platform's payout fee, then the PayPal or bank fee the platform itself pays and passes through, then an FX margin if the partner is in another currency. Each layer is small. Together they are often larger than the platform subscription.
• Disputes become three-way. When a partner says the amount is wrong, the brand says the platform calculated it and the platform says the brand approved it. With a ledger model there are two parties and one ledger both can read.
• Tax position gets murkier. The business that pays a US partner more than the reporting threshold in a year files the 1099-NEC [3]. When the platform is the payer of record, the brand may assume the platform files it, the platform may assume the brand does, and nobody does.

A platform that pays partners is a bank with a dashboard. A platform that does the arithmetic is software.

A worked month of partner payouts

Here is a month for a SaaS brand with 40 approved partners, a 20% recurring commission, the RelayWonder defaults of a 60-day cookie window, a 30-day hold and a $50 minimum payout, and one currency. We use round numbers so you can follow the arithmetic, not because real months are round.

During March the ledger gained 310 positive rows from first payments and renewals totalling $6,400 in commission. It also gained 11 negative rows: eight refunds and three chargebacks, totalling minus $340. Net commission earned in March is $6,060.

The hold period means a March commission is not payable until 30 days after the invoice was paid. The April batch therefore contains rows that cleared the hold by the batch date, not rows earned in April. Suppose $5,200 of the $6,060 clears by the April batch and the rest clears in May. Negative rows are applied immediately against the partner's balance, so the $340 of refunds reduces April's payable amount for the partners involved rather than waiting.

Now apply the minimum payout. Of the 40 partners, 22 have a payable balance of $50 or more. The other 18 have balances between $0 and $49 that carry forward. Their money is not lost; it is simply not worth a payout fee this month. The April batch is 22 lines totalling $4,870. The remaining $330 stays on the ledger as carried-forward balance.

The brand opens the April batch, sees 22 lines, checks the three partners whose balances changed because of chargebacks, and exports the CSV. Uploading 22 lines to PayPal Payouts takes about two minutes; PayPal charges a per-payment fee that the brand sees directly on its own account [4]. Wise batch payments work the same way with a spreadsheet template [5]. The brand approves, the money leaves the brand's account, and the brand marks the batch as paid in RelayWonder, which writes a payout row against each of the 22 partners. Total time, including the review: under twenty minutes.

Under the wallet model the same month looks like this: on the 1st the platform charges the brand $4,870 plus its payout fee. On a date the platform chooses, it pays the partners, minus whatever the platform's payout fee per line is. The brand did save the twenty minutes. It paid for them, and it waited.

Direct payouts step by step

If you have never run a batch from a CSV, here is the procedure we recommend. It is the same for PayPal and Wise apart from the file format.

1. Ask every partner for a payout address at approval, not at payout time. A PayPal email or Wise recipient details. RelayWonder collects this in the partner account once and reuses it across every brand the partner works with.
2. Collect tax forms at the same time. A US partner uploads a W-9; a non-US partner uploads a W-8BEN [6][7]. The form is uploaded once, verified by an operator, and the brand sees the status. Do not pay a partner whose form is missing; hold the balance and tell them why.
3. On batch day, open the batch and read the exceptions first: partners with fraud flags, partners whose balances went negative, partners whose tax status is unverified. Everything else is routine.
4. Export the CSV. One line per partner: payout address, amount, currency, a reference string you can trace back to the batch ID.
5. Upload to PayPal Payouts or Wise batch payments, review the total against the batch total, approve.
6. Mark the batch as paid. The ledger gets one payout row per partner; the partner's dashboard shows the payment the same minute.
7. Keep the payout confirmation from PayPal or Wise with the batch ID. That is your audit trail if a partner disputes a payment a year later.

What the brand gives up, honestly

The ledger model is not free of trade-offs, and we would rather name them than pretend. The brand needs a PayPal business account or a Wise business account and has to pay the payout fees itself rather than seeing them bundled. The brand has to do the twenty minutes a month. If the brand forgets, partners are paid late, and the platform cannot fix that on the brand's behalf. The brand also has to handle currency: a partner who wants euros gets euros from the brand's own Wise balance, and the brand sees the FX rate on its own statement.

For a brand doing $200,000 a month in partner-driven revenue with 2,000 partners in thirty currencies, the twenty minutes becomes a day and the convenience of a managed payout starts to earn its fee. That is the segment PartnerStack serves. Below that, the trade is lopsided in favour of the CSV.

Where the money sits at each moment

It helps to trace one commission dollar. A customer referred by a partner pays a $100 invoice on 3 March. Stripe settles that to the brand's bank account on Stripe's normal payout schedule [8]. The ledger writes a $20 row for the partner, dated 3 March, status held. On 2 April the hold expires and the row becomes payable. The April batch, generated on 5 April, includes it. The brand uploads the CSV on 6 April and the partner sees $20 in PayPal that day.

At every point in that timeline the $20 is either in the customer's account, in Stripe's settlement pipeline, in the brand's bank account, or in the partner's PayPal. There is no fifth place. If the customer disputes the charge on 20 March, the ledger writes a minus $20 row on 20 March, the partner's payable balance for the April batch drops by $20, and nobody has to claw anything back. That is the practical reason the ledger is append-only: a refund is a new row, not an edit to an old one, so the statement a partner downloads in December still adds up.

Why this scales further than it looks

People assume CSV-based partner payouts stop working at some size. In our experience the limit is not the size of the batch but the number of currencies and the number of exceptions. A 400-line PayPal Payouts file uploads as easily as a 22-line one. Wise batch payments accept up to a thousand recipients per file [5]. What grows with the program is the review: more fraud flags, more negative balances, more partners whose tax forms expired. RelayWonder puts those exceptions at the top of the batch screen precisely so that the review stays short when the batch gets long.

The other thing that scales is the partner side. A creator who works with eight brands does not want eight PayPal payments from eight platforms on eight dates. With one partner account across all brands and one balance per currency, the partner sees one ledger. Each brand still pays its own batch from its own account; the partner simply sees them in one place. That is the most we can do without becoming the payer, and it is enough.

What this means for partners

Partners sometimes ask why a platform that calculates their money does not simply pay it. The answer we give is that the brand paying directly is a feature for them too. The partner is paid by the company whose product they promoted, under that company's terms, with that company's name on the PayPal line. If the brand is late, the partner can see the batch status and knows who to ask. If RelayWonder disappeared tomorrow, every ledger row and every payout confirmation would still exist in the brand's PayPal or Wise history, and the brand would still owe exactly what the terms say. Partners never pay us anything, on any plan, and we never take a percentage of their commission. Holding their money would be the first step toward both.