About
Built for the Mercury era.
We started Cobalz because every other affiliate platform felt like it was built before Stripe Connect existed, before Mercury existed, before the word “OpenAPI” meant anything. We're fixing that.
The story.
Cobalz started as an internal tool. We were running an e-commerce brand on WooCommerce with a Mercury business account, and our affiliate program ran on Refersion. Every Friday someone on the ops team spent four hours exporting CSVs, uploading to PayPal Mass Payments, fixing rejection reasons, then manually reconciling.
We thought: Mercury has an Invoicing API. Why is no platform using it? We built a 200-line script. The script became a service. The service grew teeth: row-level security, refund clawback math, tier auto-promotion, multi-payout adapters, a documented REST API. Eventually it was 90% of what an affiliate platform needs to be.
We open-sourced the WordPress plugin, productionized the rest, and shipped Cobalz Affiliate. The product you can use today is the same one we use to pay our own affiliates every Friday — except now it takes 90 seconds instead of four hours.
Where we are
The numbers.
- 60+
- Routes shipped
- 4
- Payout rails
- 2
- Storefronts native (WC + Shopify)
- 12
- Outbound webhook event types
What we believe.
- Audit-log everything. Every state transition is a row in
audit_log. No silent fixes, no “trust me” reconciliation. - Math should still work in 90 days. We persist the winning rule's rate + basis on every commission so a refund 3 months later resolves correctly.
- Standards beat custom protocols. Standard Webhooks v1, OpenAPI 3.1, Web Crypto for HMAC, RFC 8058 one-click unsubscribe, OAuth 2.0 everywhere.
- Per-merchant secrets in Vault, never in app DB. Mercury keys, plugin shared secrets, TINs, OAuth tokens — all per-merchant Vault entries.
- RLS or it didn't happen. Postgres row-level security on every tenant-scoped table. Cross-tenant data exposure is structurally impossible.