你如果已经有一个 iOS App、一个 Android App，再加一个 Web 落地页，最烦的不是多写一个支付按钮，而是订阅权益散在三套后台：App Store、Google Play、Stripe Billing。客服问「这个用户到底有没有 Pro」，你要在三个地方查。
2026-04-17，RevenueCat 宣布 Web purchase flows 支持销售 Stripe Billing 产品和订阅，并支持 Stripe Managed Payments。它不是让你离开 Stripe，而是让 Stripe Billing 产品进入 RevenueCat 的 Web Purchase Links、Web SDK、Web Paywalls、Web Funnels 和 Redemption Links 这些购买入口。
它改变了什么
不接入时，Web 端用 Stripe Checkout 收款，App 端用 RevenueCat 管 App Store / Google Play 订阅。两个世界可以通过 webhook、customer id 和自建数据库接起来，但 entitlement 容易乱。
接入后，Stripe Billing 的购买可以纳入 RevenueCat 的订阅视角。对独立开发者最现实的意义是：Web 首购、App 登录、跨端恢复订阅这几件事少写一套胶水代码。
| 链路 | 不接 RevenueCat Stripe Billing | 接入后得到什么 |
|---|---|---|
| Web 购买 | Stripe Checkout + 自己处理 entitlement | Stripe Checkout 仍在，购买进入 RevenueCat entitlement |
| App 权益 | RevenueCat 管 App Store / Google Play | App 和 Web 订阅更容易放到同一用户视角 |
| 落地页 | 自己做支付页和 webhook | 可用 Web Purchase Links、Web Paywalls、Web Funnels |
| 客服查询 | 多后台交叉查 | RevenueCat 里能看到更多订阅上下文 |
优先使用的团队类型
第一类是 App 起家、后来补 Web 订阅的产品。比如 iOS 已经通过 RevenueCat 管订阅，现在官网要卖年付套餐，不想让 Web 用户变成另一套账号体系。
第二类是 Web-to-App funnel 明确的团队。用户先在浏览器看功能页、填问卷、过 paywall，然后下载 App 使用。RevenueCat Web Funnels 和 Web Paywalls 对这类链路更自然。
第三类是已经有 Stripe Billing 产品，但移动端 entitlement 处理得很痛苦的团队。尤其是客服经常查「Web 买了年付，App 里还是 Free」时，订阅中控的价值会比支付按钮本身更大。
暂时不接入的情况
如果产品只有 Web SaaS，没有 App Store、Google Play，也没有跨端 entitlement，直接用 Stripe Billing 通常更省事。RevenueCat 这时会变成另一层后台。
如果商业模式依赖复杂价格，也要停一下。RevenueCat 文档写明 Web purchase flows 支持 flat rate 的一次性或周期性价格；阶梯价、用量计费、客户自选金额不支持。免费试用和优惠券输入也不是 RevenueCat purchase flows 的主路径。
团队匹配决策
| 当前状态 | 默认选择 | 放弃条件 |
|---|---|---|
| App 订阅已在 RevenueCat，准备卖 Web 年付 | 用 RevenueCat Stripe Billing | 价格不是 flat rate，或强依赖优惠码输入 |
| 只有 Web SaaS | Stripe Billing 直连 | 近期要上 iOS / Android 并统一权益 |
| Web-to-App funnel 是主增长入口 | 用 RevenueCat Web Funnels + Stripe Billing | 落地页需要复杂自定义 checkout |
| 需要 MoR 税务链路 | 评估 Stripe Managed Payments | Stripe 账号、权限或 tax code 不满足 |
| 用量计费、阶梯价 | 暂不放进 RevenueCat purchase flows | 可以只同步外部购买 |
Stripe Managed Payments 的定位
Stripe Managed Payments 是 Stripe 的 Merchant of Record 功能。RevenueCat 文档说明，在 Stripe Billing 集成里启用后，客户通过 Stripe Checkout 付款，符合条件的交易由 Stripe 处理税务计算、收取和申报相关责任。
限制有两条：它只能通过 RevenueCat 的 Stripe Billing integration 使用，不适用于 RevenueCat Web Billing；也不是每笔交易都保证走 Managed Payments。产品 tax code、Stripe 账号状态和 RevenueCat Stripe App 权限都要满足要求，不合格产品会回落到标准 Stripe Billing checkout。
本文不提供法律或税务意见，跨地区销售前仍应让会计或税务顾问看产品类型和客户分布。
上线前测试清单
最小测试集包括：Stripe sandbox 连接 RevenueCat；创建 flat rate 的订阅产品；导入 RevenueCat Product Catalog；创建 Offering 和 Package；用 Web Purchase Link 或 Web SDK 发起购买；付款后检查 RevenueCat entitlement；App 端登录同一用户；打开 managementUrl 进入 Stripe Customer Portal；取消订阅后等待同步。
别只测付款成功。用户买完之后，在哪里取消、哪里下载收据、哪里改套餐，这些都要写进客服文档。
未覆盖的限制
没有实测 Stripe Managed Payments 的真实结算、税务申报、发票抬头和各国家地区责任划分。也没有验证所有异步支付方式、退款争议、proration、历史迁移异常的表现。官方文档能支撑的是产品链路和功能限制，不等于你的公司在某个司法辖区一定合规。
如果你的订阅产品还在选收款底座，把 MoR 和 PSP 的取舍放到 Stripe vs Lemon Squeezy vs Paddle vs Polar 收款方案决策矩阵 里比较。AI SaaS 还要看 credit、用量和订阅组合，可接着看 Polar vs Stripe Billing credits 对比 和 Stripe 用量计费 v2。