rc-revenuecat-vs-raw-billing

RevenueCat 与原始 Google Play Billing

阶段 0：意图

当你需要在集成 RevenueCat 和直接接入 Google Play Billing Library（PBL）之间做选择，并想了解哪些事项会因此免除、哪些事项会转移，以及哪些事项仍由你的团队负责时，请使用此技能。此决策涵盖 Android 客户端，以及支持订阅或一次性购买的任何服务端基础设施。

此技能通常解答以下问题：

• 如果采用 RevenueCat，我的应用中哪些客户端代码可以不再编写？
• RevenueCat 会替代哪些后端部分（收据验证、RTDN、状态机）？
• 无论选择哪种方案，哪些事项仍由我负责？
• 目前是否有只有原始 PBL 才能处理的事项？

阶段 1：定位事项

在阅读表格之前，先确定你实际要评估的内容。将需求归入以下类别之一，并跳转到相应部分：

类别	示例	前往
客户端购买处理	BillingClient、监听器、确认、消耗	客户端表格
服务端购买状态	令牌验证、RTDN、权益状态机	服务端表格
两者均不涉及	身份验证、你的用户数据库、付费墙 UI、推送	你的责任表格

如果某项工作涉及多个方面（例如 RevenueCat 验证令牌，但你仍需在 API 上限制高级内容的访问），那么即使验证本身已有人处理，集成衔接工作仍由你负责。

阶段 2：对照参考

客户端

事项	原始 PBL	RevenueCat
BillingClient 设置和配置	由你编写	内部处理
连接生命周期和重新连接	由你编写	内部处理
PurchasesUpdatedListener	由你编写	由购买回调替代
queryProductDetailsAsync()	由你编写	由 awaitOfferings() / awaitGetProducts() 替代
launchBillingFlow()	由你编写	在 awaitPurchase() 内部调用
购买后确认	由你编写	自动处理
消耗型商品的消耗	由你编写	自动处理（在控制面板中将商品标记为消耗型）
启动时调用 queryPurchasesAsync()	由你编写	连接时内部处理
瞬时错误的重试逻辑	由你编写	由 SDK 内部处理
BillingResponseCode 处理	由你编写	抽象为 PurchasesErrorCode
应用内支付恢复消息	由你编写	自动处理（showInAppMessagesAutomatically = true）
优惠的订阅选项选择	由你编写	自动选择 defaultOption

服务端

事项	原始 PBL	RevenueCat
Google Play Developer API 集成	由你构建	RevenueCat 后端
服务账号凭据管理	由你管理	在 RC 控制面板中配置一次
每次购买时验证收据	由你构建	自动处理
购买令牌验证和去重	由你构建	RevenueCat 后端
linkedPurchaseToken 链遍历	由你构建	RevenueCat 后端
RTDN 处理和分发	由你构建	RevenueCat 负责处理并发送 Webhook
Cloud Pub/Sub 设置	由你设置	无需设置
后端订阅状态机	由你构建	由 RC 计算 CustomerInfo
跨 7 种状态计算权益	由你构建	由 RC 计算 isActive
宽限期 / 账号保留跟踪	由你构建	billingIssueDetectedAt
取消后访问权限持续至到期的逻辑	由你构建	isActive + unsubscribeDetectedAt
价格群组跟踪	由你构建	由 RC 后端处理
商品到权益的映射	由你构建	在 RC 控制面板中配置

无论选择哪种方案，以下事项仍由你负责

事项	说明
用户身份验证系统	由你提供；将用户 ID 传给 RC
自有用户数据库	RC 不是你的主要用户数据库
服务端高级内容	通过 RC REST API 或 Webhook 验证
Webhook 接收端点	由你构建；RC 发送，你接收
Play Console 产品创建	仍需在 Play Console 中完成
订阅延期	直接调用 Google Play API
订阅撤销	直接调用 Google Play API
替代计费计划	RC 支持有限；可能需要使用原始 PBL
应用 UI（付费墙、引导流程）	由你构建（RC Paywalls UI 可选）
针对支付问题的推送通知	基于 Webhook 事件由你构建

第 3 阶段：推荐判定规则

使用以下规则，根据表格做出决策：

1. 如果你的应用需要订阅延期、订阅撤销，或 RevenueCat 尚未支持的替代计费计划，请计划为这些特定调用保留原始 PBL 路径，无论你的主要选择是什么。
2. 如果你原本需要从头构建收据验证服务、RTDN 管道和订阅状态机，那么服务端表格至少列出了 RevenueCat 可以免除的八项工作。除非你有明确理由要自行负责这套体系，否则请选择 RevenueCat。
3. 如果你已经有成熟的计费后端，并且已验证令牌、测试过状态处理，那么收益会小一些。请将其与 RevenueCat 在客户端的简化功能和由控制面板驱动的产品目录进行权衡。
4. 务必确认“仍由你负责”表格中的事项都有人负责。RevenueCat 不会替代你的身份验证、用户数据库、付费墙 UI 或高级内容访问控制。传递 appUserID，并通过 REST API 或 Webhook 在服务端验证权益，仍然是你的责任。
5. 如有疑问，请将每项需求映射到三个表格中的某一行。落在“仍由你负责”表格中的事项，无论选择哪种方案，成本都相同，因此不应影响决策。

快速判断：

need custom RTDN pipeline?      -> raw PBL only if you must own it end to end
need deferral or revocation?    -> keep a raw PBL path for those API calls
need fast time to production?   -> RevenueCat, then add raw PBL escape hatches later

参考资料

• 完整章节