The status quo
Look at any affiliate platform built in the last decade and you'll find the same payout story: log in, export a CSV of pending payouts, upload to PayPal Mass Payments or your payroll software, type a confirmation, wait three to five days, and then manually match transactions when you reconcile next month.
Goaffpro does this. Refersion does this (and charges 2.5% on top). FirstPromoter does this. UpPromote does this. Every Friday afternoon someone on the operations team sets aside half a day to pay affiliates — and that's for a small program. At a hundred affiliates the work compounds; at a thousand it's somebody's full-time job.
Mercury changes the math
Mercury ships an Invoicing API. You can programmatically issue an invoice to any payee, point it at one of your bank accounts as the destination, and Mercury handles the rest: email delivery, hosted-pay page, ACH settlement, status webhooks. The payee doesn't need a Mercury account — they just open the email, click pay, and the funds are en route.
Stripe Treasury can do similar things in its own ecosystem. So can Modern Treasury if you're a fintech with a fintech budget. But Mercury is the bank that tens of thousands of small e-commerce, SaaS, and creator businesses already use, and the API is one of the cleanest we've worked with. Yet no affiliate platform integrated with it.
What we built
Cobalz pairs each merchant's Mercury account with a per-merchant API key invault.secrets. An hourly cron checks every merchant in their local timezone, and when today is your scheduled payout day (daily, weekly Friday, biweekly, monthly 1st, monthly 15th, or on-demand), the aggregator picks every affiliate above min_payout with approved commissions in the period.
For each one we ensure a Mercury customer exists (cached on first invoice), then create the invoice with a deterministic idempotency key derived from(merchant_id, affiliate_id, period_hash). A unique constraint on the payouts table guarantees we can't double-issue if the cron retries. The Mercury hosted-pay URL goes back into the payout row so the affiliate can click straight from our email.
When the affiliate pays, two things happen in parallel: Mercury fires atransaction.created webhook to /api/mercury/webhook/[merchantId]and our 15-minute reconciliation cron polls the invoice status. Whichever path wins runs the same atomic UPDATE … WHERE status <> ‘paid’ RETURNING claim, then runs the lifetime-accrual side effects exactly once.
The differentiation in one sentence
For a US store that already banks with Mercury, payday goes from a four-hour manual task to a one-click confirmation — and the audit trail (audit log row per transition, idempotency keys at every layer, hosted-pay URLs in every payout row) is better than most banks' own internal records.
What about non-Mercury merchants?
Mercury is one of four payout rails. PayPal Mass Payments, Stripe Connect, and Wise are wired with the same idempotency primitives. Per-affiliate payout method + per-payout currency + daily FX from OpenExchangeRates means a global program with US affiliates on Mercury and EU affiliates on Wise just works.
The reason we built Mercury first is the wedge. Every other rail is table stakes that affiliate platforms have shipped for a decade. Mercury is the differentiator that no one else has.
Try it: /features/mercury-payouts · payout walkthrough