Stripe vs Paddle：SaaS 收款费用、税务责任与上线检查

Stripe vs Paddle，先选的是销售责任怎么分工，再选支付费率。 希望灵活组合支付能力、也能管理销售和财务工作的团队，可以优先评估标准 Stripe；符合准入条件、希望采用一体化 Merchant of Record 服务的软件团队，可以优先评估 Paddle。无论选哪家，把付款结果接到自己的产品权限，仍然需要认真实现。

比较时还必须加入 Stripe Managed Payments。它也是 MoR 方案，不能再简单地把两家概括成“Stripe 不管、Paddle 全管”。本文区分三种配置，给出开户核对项、两组成本算例和上线演练清单。官方资料核对日期为 2026 年 10 月 14 日。

Stripe vs Paddle：先把三种配置分清

Merchant of Record，简称 MoR，可以理解为向买家承担销售责任的交易商家。处理付款、管理订阅、承担 MoR 责任，是三个相关但不同的角色。

这张表用于划分责任，不是平台排名。有些团队需要高度可组合的能力；有些团队更需要减少日常销售运营工作。先写清实际需求，才能判断灵活性和托管服务各值多少钱。

国内开发者先查什么：主体、产品与收款账户

先写下五项：真正的销售主体、注册地区、产品类型、主要买家地区、拟使用的收款银行。 “网站面向全球”不能回答商户账户应该在哪里开。

Stripe 商户地区支持页用于核对基础可用范围；Managed Payments 准入说明则要另外检查。已有标准 Stripe 账户，不代表其中每项服务都能直接启用。产品名称相近，也不能替代对经营地区、产品和账户类型的逐项核实。

Paddle 的供应商地区限制和买家地区支持回答的是不同问题。能向一个地区的客户销售，不等于该地区的所有主体、产品和银行账户都能通过审核。

对于国内开发者，个人在哪里居住、公司在哪里注册、谁实际经营、款项进入哪个账户，需要分别确认。不要根据中文网站、某种付款方式或别人的开户经历推断自己的资格。向平台说明真实产品和主体，在投入接入开发前得到明确反馈；即使另行设立主体，也会有相应维护工作，不是修改一个国家选项就结束。

MoR 解决哪些税务工作，哪些还需要自己负责

标准 Stripe 配置下，购买税务工具并不自动把 Stripe 变成交易商家。Stripe Tax提供相关能力，但你启用了什么服务、覆盖什么环节，仍要明确。登记、计税、代收、申报和缴纳不要混成一句“已经处理税务”。

Paddle 的 MoR 模式和 Stripe Managed Payments，会改变所覆盖交易中相关销售税务工作的分工。这对小型软件团队可能有价值，但不意味着自己的公司记账、所得税及所有本地义务都已经外包。

实用做法是列一张责任表：每项任务写上负责人、依据和待确认问题。例如“谁审核退款”“谁做月度对账”“销售税务资料由谁保管”。与其笼统问平台管不管税，不如把真实配置和未解决的问题交给财务人员核对。发现某一项没有人负责，比笼统比较功能数量更有用。

先演练一笔订阅，再决定接哪家

假设你的网站卖每月 10 美元的会员。画出三条泳道：买家、支付平台、你的网站。从点击定价页开始，一直走到用户取消订阅、剩余已付费时间结束。

可以用泳道图模板记录交接点。它是通用图示，需要替换成自己的价格、事件和权限规则，并不是可以直接运行的支付集成。不了解如何划分责任时，可以先看泳道图示例。

泳道图

试试这个模板

让两个候选方案回答同一笔业务，比单独看各自演示更容易发现缺口。这里演练的是责任和流程；真正的支付接受率、账户审核或合规结果，需要另外验证，不能靠画完一张图就下结论。

手续费怎么算：同样收入，客单价不同结果也不同

以下费率来自本次核对的官方页面：Stripe 美国本地卡处理费为 2.9% + 0.30 美元；Billing 按量方案为 Billing 交易量的 0.7%；Paddle 公开按量方案为每笔结账交易 5% + 0.50 美元；Managed Payments额外收取 3.5%，支付处理和订阅 Billing 费用另计。

下面只是计算模型，不是面向所有地区的报价。 假设主体是符合条件的美国商户，全部使用美元、本地卡，订阅扣款成功，没有销售税。暂不计国际卡附加费、换汇、退款、争议、出款、其他服务和议价合同；每笔金额全部计入对应费基。

计算方法是“收入 × 百分比 + 笔数 × 固定费”，再加上对应服务费用。同样收入下，交易笔数不同，固定费用的影响也不同。

这些数字不能直接当利润。标准 Stripe 的差额还要覆盖业务所需的其他服务和运营工作；购买组合服务，也不代表支付转化率更高或产品一定赚钱。做预算时要替换成自己的商户地区、付款方式、合同和实际税务口径。Managed Payments 的百分比费基包含适用的间接税，因此这里明确采用无税假设，不能照搬到含税销售额。

订阅接入的难点，是付款状态和产品权限一致

结账页能弹出来，和付费产品可以可靠运行，是两回事。至少为首次购买、续费、升级、降级、取消和退款各写一个验收场景。还要加入“客户付完钱就关闭页面，没有跳回网站”的情况。

Stripe 的订阅事件说明和 Paddle 的权限同步说明可以作为事件映射的依据。你仍要定义用户能使用什么功能、到什么时间，以及哪些变更要延后生效。计费状态不会自动替你定义所有产品规则。

按 Stripe和 Paddle 的官方方式验证 Webhook 请求，将事件关联到正确用户，处理重复投递，避免重复开通权益。旧事件迟到时，要能结合平台当前状态判断，避免把已更新的权限改回去。

宽限期尤其要明确：续费失败后，是立刻停用、暂时保留，还是只开放部分功能？到期取消不能误伤用户已经付费的使用时间。如果卖的是额度，还应单独规定退款如何影响剩余额度。先确定规则，再实现和测试，比看到一个状态就临时加判断更稳妥。

出款、退款与迁移，提前问清楚

后台显示收入，不等于银行已经收到可支配款项。请平台确认自己的结算币种、出款周期、门槛、换汇、可能的留存或审核条件，再安排服务器和支持成本。不要把支付成功时间直接当成现金到账时间。

退款流程也要落到人和记录：用户向谁提出请求，谁批准，平台记录什么，网站怎么调整权限，财务怎样对账。不能默认退款会退回所有原手续费，也不能默认一次退款就处理好了未来订阅续费；需要核对具体条款和配置。

如果已有付费用户，换平台前要盘点客户 ID、订阅、付款凭据、历史账单、折扣和站内权限。能导出客户名单，不代表能直接转移付款凭据或扣款授权。先确认平台支持的迁移方式，保存新旧 ID 对照，并演练跨续费日期的情况，避免用户被重复收费或失去已付费权限。

哪种团队优先评估哪种方案

这张选择表是根据官方服务模型作出的判断，不是支付转化率或客服质量排名。我们没有为本文开户、真实扣款或测试客服速度；这些问题应进入你自己的评估清单，不能从功能表推断。

网站开启真实收款前的检查清单

• 确认销售主体、产品类别和出款账户符合要求。
• 确认谁是 MoR，剩余财务工作分别由谁负责。
• 定价、自动续费、取消、退款和联系方式与真实行为一致。
• 正式环境中的价格、币种、产品和用户关联正确。
• 验证 Webhook 签名，并测试重复、延迟和失败投递。
• 在平台支持的测试环境演练购买、续费失败、取消和退款。
• 核对付款状态和产品权限，包括预定生效的变更。
• 准备对账、客户支持，以及首次出款前的现金安排。

每一项写上负责人和复核日期。支付接入只是网站做好并盈利的一环；在用户到达结账前，还需要回答产品适不适合、如何使用、值不值得购买，可以用内容映射的方法规划这些页面。先把责任和计算假设说明白，再选择平台、验证集成，最后开启真实销售。

从平台比较继续到上线实现

用 SaaS 收款方案选择收敛实际配置，再按订阅计费流程明确权限、续费、取消和异常行为。