出海 SaaS 做联盟计划：自研要写哪些模块，什么时候直接用 RelayWonder

出海做订阅制 SaaS 或 DTC 品牌，到一定阶段都会想做联盟计划：让博主、测评站、Newsletter 作者和行业创作者推荐产品，成交之后按约定付佣金。需求听起来只有一句话——给每个伙伴一条链接，成交了记一笔——可真正写成系统，会牵出归因、订阅续费、退款、跨境付款、税表、反作弊和伙伴自助后台，每一块都有自己的坑。我们做平台与系统开发时常被问到同一个问题：这套东西自己写，还是用现成的？本文先从开发公司的视角把自研的工作量拆开，再介绍 RelayWonder 这款面向 SaaS 与 DTC 品牌的伙伴网络怎么接入、收多少钱，以及它目前做不到的事。

InsightWonder、RelayWonder 与本站（大乐GEO / 大乐网络）属同一团队运营；本文按两款产品官网公开信息撰写，价格与功能以官网为准。

先把需求拆开：联盟计划其实是七个模块

在业务方眼里，联盟计划是「找人推广、按成交分钱」。在开发方眼里，它至少是下面七个相互依赖的模块。少做任何一个，上线后都会以对账纠纷或伙伴投诉的形式补回来。

1. 归因：伙伴链接、落地页脚本、cookie 与优惠码，以及多个伙伴碰过同一个用户时算谁。
2. 计佣规则：首单赏金、续费抽成的比例与时长、阶梯与里程碑。
3. 支付事件处理：接收支付平台的 Webhook，把成交、续费、退款、争议、取消转成佣金动作。
4. 佣金账本：每一笔佣金从产生到冲回、到付款的完整记录，以及由此得出的余额。
5. 付款与税表：跨境批量付款、最低起付金额、税务表单收集与保管。
6. 反作弊：自我推荐、刷点击、异常退款与付款暂缓。
7. 伙伴门户：注册、领链接和优惠码、看数据、填税表、下载对账单。

自研时每一块的坑

归因：cookie 会丢，优惠码要补位

最常见的做法是伙伴链接带一个参数，落地页脚本读到参数后写进 cookie，用户付款时再把 cookie 里的伙伴标识带进支付会话。问题在于链路很容易断：用户在手机 App 内置浏览器里点了链接，几天后在电脑上付款；或者中间清过 cookie、换过浏览器。优惠码是补位手段，用户结账时输入伙伴专属码，不依赖浏览器状态。两者冲突时谁优先、多个伙伴都触达过同一个用户时按末次触点还是首次触点算，这些都要写进规则并对伙伴公开，否则每一次争议都要人工判断。

如果结账用的是 Stripe Checkout，伙伴标识一般放进 client_reference_id。按 Stripe 的 Checkout Session 接口文档，这个字段用来把会话与你自己系统里的记录对上，可以是客户 ID、购物车 ID 之类，最长 200 个字符。它只是一个对账字段，Stripe 不会替你判断这笔成交该给谁、该给多少，后面的事全部要自己写。

订阅续费：按每张发票计佣

订阅制产品的佣金不是一次性的。常见结构有首单赏金、按续费收入抽成若干个月或终身、按业绩分阶梯、达到里程碑给奖励。系统必须在每一张续费发票支付之后算一笔，而不是在首次结账时记一笔就结束。升级、降级、按比例计费、试用转付费、使用优惠券后的实收金额，都会改变每张发票的实际收入，佣金基数要以发票实收为准，否则月底财务对不上账。

Webhook：事件会重复，也会乱序

上面这些都靠支付平台推送的事件驱动。Stripe 的 Webhook 文档写得很直白：事件不保证按产生顺序送达，同一个事件可能送达不止一次，建议记录已处理的事件 ID 来去重；处理端要先校验签名，并尽快返回 2xx，复杂逻辑交给异步队列。很多自研联盟系统的第一次线上事故就出在这里：同一张发票记了两次佣金，或者退款事件比支付事件先到，冲回时找不到原记录。

退款冲回与冻结期

用户付款后退款或发起争议，已经计出的佣金要收回。通常分两层处理。第一层是冻结期：佣金产生后先处于待结算状态，过了冻结期才进入可付款余额。第二层是冲回：退款发生时写一笔负数记录抵消，而不是删掉或改小原记录。冻结期定得太短，钱付出去了退款才来，很难再从伙伴那里要回；定得太长，伙伴会觉得结算慢、积极性下降。

只追加的账本

佣金账本应当只追加、不修改：每次产生、冲回、人工调整、付款都是新的一行，余额由所有行累加得出。这样任何一笔都能追溯到哪张发票、哪个事件、谁在什么时候调整过，出现争议时能给伙伴一份完整对账单。直接用一条 update 改余额字段的做法前期写得快，一旦出错就无从查起。

跨境付款与税表

伙伴分散在不同国家，付款渠道多半是 PayPal 或 Wise。批量付款要生成符合渠道格式的文件，还要处理最低起付金额、币种和付款失败。对面向美国市场的品牌，税表是绕不开的一环：按 IRS 的说明，Form W-9 用于向需要提交信息申报的一方提供正确的纳税人识别号；作为收入受益所有人的境外个人，则在付款方要求时提供 Form W-8BEN。表单收集、到期提醒、加密存储和访问留痕都要做，因为这些都是敏感个人信息。年底是否要开具信息申报表、开哪种，取决于品牌主体的情况，应当咨询自己的税务顾问。

反作弊

联盟计划天然会招来作弊：伙伴用自己的链接给自己下单拿佣金；刷点击制造虚假流量；优惠码被转贴到折扣聚合站，抢走本该属于其他伙伴的归因；先付款拿佣金再退款。最低限度要做自推屏蔽、点击异常标记，以及对高风险伙伴的付款暂缓。

伙伴门户与披露要求

伙伴需要一个自助后台：注册、领取链接和优惠码、查看点击与佣金、填写税表、下载对账单。门户最好挂在品牌自己的子域名下，伙伴更容易信任。还有一个常被忽略的合规点：美国 FTC 要求推荐者清楚披露与商家之间的利益关系，FTC 关于背书指南的问答提到，在联盟链接旁边紧挨着写上「paid link」这类说明是可以接受的披露方式。计划条款里应要求伙伴做披露，门户里也应提示。

把这七块加起来，自研一个能放心上线的联盟系统，工作量通常以月计，具体取决于计佣规则的复杂度、要接几个付款渠道、伙伴门户要做到什么程度；上线之后还要持续维护事件处理、对账和伙伴支持。

什么时候应该自研

现成平台省的是通用部分的工作量。以下几种情况，通用部分恰好接不上，自研更合适：

• 支付不走 Stripe：例如自建结账、Paddle、WooCommerce，或者面向大陆用户的微信支付、支付宝。现成的 Stripe 方案接不进去，只能自研或等待支持。
• 计佣规则深度依赖产品内部数据：例如按席位数、按用量、按客户行业分档，规则需要读取支付平台之外的业务数据。
• 联盟本身是产品功能的一部分：例如平台要给自己的用户发推广佣金，数据和资金流必须留在自己的系统里。
• 合规或采购要求数据不出自有系统，或者要求供应商提供完整的合同与隐私条款。

这些情况下，前面列的七个模块要逐个设计，模块之间按 API 契约拆清楚，事件处理一律走队列，账本只追加。这类定制开发本身没有捷径，但模块边界想清楚了，后期改规则不会牵一发动全身。

什么时候直接用现成平台：RelayWonder 做了什么

如果你的结账走 Stripe、规则是常见的订阅制结构，自研的大部分工作就是在重复造轮子。RelayWonder 是面向 SaaS 与 DTC 品牌的伙伴网络，一个账户里管理联盟客（affiliate）、创作者（creator）与媒体发布方（publisher）三类计划。按它的产品功能页，流程分为招募、激活、追踪、计佣、优化五步。它的几个设计点，正好对应前面列的自研难点：

• 追踪绑定 Stripe 发票，续费按发票计佣；默认末次触点，可选首次触点；官网写明「优惠码优先于 cookie」。
• 账本只追加，退款写一笔负数记录，并有冻结期与冲回机制。
• 每月生成 PayPal Payouts 或 Wise 批量 CSV，从品牌自己的账户付款，平台不经手资金。
• 计佣支持按月续费百分比（可设定月数或终身）、首单赏金、阶梯与里程碑。
• 反作弊包括自推屏蔽与点击异常标记；付款暂缓在 Scale 档提供。
• 伙伴用一个账户、一个余额参与所有品牌的计划，另有公开的计划市场。

开始之前想先估算佣金成本，可以用它的佣金计算器；续费抽成比例与时长怎么设，官网有一篇订阅制佣金结构指南；从零起步的完整流程见SaaS 联盟计划起步指南。付款渠道与 W-9 / W-8BEN 的处理方式，另有一篇PayPal、Wise 付款与税表指南。

接入：一行脚本加两处配置

按官网的安装文档，接入分三步：

1. 在站点页面放一行脚本标签，访客经伙伴链接进入时记录 rw_ref。
2. 创建 Stripe Checkout Session 时，把 rw_ref 作为 client_reference_id 传进去。
3. 完成 Stripe Connect 授权，把品牌的 Stripe 账户连上。

官网的说法是「开发者加一行代码，大约 10 分钟」。从开发角度补充一点：实际耗时取决于你现有的结账代码。如果 Checkout Session 由后端创建，需要把前端读到的 rw_ref 传给后端接口；如果结账不经过自己的后端代码，要先确认这个字段能否传进去。测试时可以在链接后加 ?via=test 走一遍。

接入后它监听五类 Stripe 事件：

• checkout.session.completed：结账完成，对应首单成交。
• invoice.paid：发票支付，续费佣金按这里计算。
• charge.refunded：退款，对应佣金冲回。
• charge.dispute.created：争议发起。
• customer.subscription.deleted：订阅取消。

为什么按发票而不是按结账归因，官网有一篇按 Stripe 发票归因的说明，自研的团队也可以拿来对照自己的设计。

白标门户、追踪域名与 API 权限边界

伙伴门户可以白标挂在 partner.yourbrand.com，配一条 CNAME 即可，HTTPS 自动签发；追踪域名可以设为 go.yourbrand.com，在品牌根域名下写入 rw_ref cookie。伙伴看到的是品牌自己的域名，追踪 cookie 也落在品牌自己的域名下。域名解析和多站点部署的常见做法，可以参考我们的跨境出海解决方案。

对开发方更值得关注的是权限边界。RelayWonder 提供 MCP 端点和 REST API，密钥按权限范围分为 read、campaigns、invite 三种。批准付款、修改银行信息、添加团队成员、轮换密钥这几项不作为工具开放，官网原话是「以后也不会」。也就是说，可以让 AI 智能体去招募伙伴、写合作 brief、发邀请，但涉及钱和账户权限的动作必须由人在后台完成。细节见MCP 端点说明。

AI 招募工具 Hunter 会从 YouTube、博客、Newsletter、Reddit 以及竞品的联盟足迹里挖掘潜在伙伴，给出 A / B / C 等级、0–100 分、书面理由和风险标记；每滚动 7 天上限 150 个，只收录有公开商务邮箱的对象；对 Instagram、TikTok 不做受众核验。Hunter 只在 Scale 及以上档位提供。

另一个功能是内容合作：根据 AI 搜索里的缺口生成内容 brief，伙伴每交付一篇内容拿一笔赏金，再叠加成交佣金，内容链接一路追踪到成交。Scale 档可以接入 InsightWonder 的 AI 搜索缺口数据，并对交付内容做 AI 引用追踪。

价格与默认设置

按价格页，所有档位都是「0% 联盟收入抽成」，伙伴永久免费：

• Free：0 美元，适用于每月联盟收入 1,000 美元以内；1 个计划，伙伴数不限，Stripe 上的链接与优惠码追踪，月度 PayPal / Wise 付款文件，计划市场页面，对账单与税表。
• Growth：每月 49 美元，每月联盟收入 10,000 美元以内；计划与团队成员不限，带赏金的内容合作，伙伴邀请与外联草稿。
• Scale：每月 129 美元，每月联盟收入 50,000 美元以内；InsightWonder 的 AI 搜索缺口、交付内容的 AI 引用追踪、MCP 端点与 API 密钥、带付款暂缓的点击反作弊、Hunter。
• Enterprise：定制报价。

按年付费「送 2 个月」。默认参数是 cookie 有效期 60 天、冻结期 30 天、最低起付 50 美元。

与同类工具的对比，官网有一个对比页面，里面引用的竞品价格都标了核对日期：Rewardful 与 FirstPromoter 49 美元起（2026-09-18），Partnero 每月 59 美元起且没有免费档（2026-09-19），PartnerStack 按报价（2026-09-26）。它在与 Partnero 的对比里也承认，如果这周就需要网页伙伴发现功能，Partnero 已经能用。

目前的限制，接入前先看清

• 只支持 Stripe。Shopify 标注为「即将推出」；WooCommerce、Paddle 与自建结账暂不支持。这类情况要么自研，要么等。
• 网络还处在早期：计划市场目前只显示 2 个计划，网络里联盟客数量为 0。伙伴现阶段要靠品牌自己带来，不要指望平台导流。
• 官网还没有关于我们、服务条款和隐私政策页面，联系方式是 support@relaywonder.com。法务与采购审核严格的公司，签约前要先把合同条款谈清楚。
• 平台不开具 1099，这部分由品牌自己处理。
• Hunter 只在 Scale 及以上提供，且不核验 Instagram、TikTok 的受众。
• 整体面向美国市场：税表是 W-9 / W-8BEN，计价是美元。面向大陆用户、走微信支付与支付宝的业务不适用。

官网另有一篇「我们不做什么」，列明不做代管付款、不做亚马逊渠道、不做代运营服务、不从佣金里抽成、不制造虚假活跃。对评估供应商来说，这类边界声明和功能清单一样有用。

一个可以照着走的判断顺序

1. 结账是否走 Stripe？不走，就自研或等待支持，后面的问题不用再看。
2. 计佣规则是否要读支付平台之外的业务数据？要，倾向自研。
3. 联盟收入规模多大？先用 Free 档把链接、优惠码、Webhook 和付款文件跑通一遍，再决定是否升级。
4. 是否需要 AI 招募、API 或让智能体参与运营？需要的话看 Scale 档。
5. 法务与采购审核有什么要求？在条款页面上线之前，先通过邮件确认合同细节。

不管走哪条路，上线前都要把计划条款写清楚：佣金比例与时长、归因规则、冻结期、退款冲回、起付金额和披露要求。RelayWonder 提供一个计划条款生成工具，可输出中英文，但官网注明未经法律审核，正式使用前应请律师过一遍。

如果你评估下来决定自研，或者结账不走 Stripe、需要和现有订单与会员系统做定制对接，可以按我们的合作流程先做一轮需求梳理，把计佣规则、事件处理和账本结构定下来再动手。