rc-revenuecat-vs-raw-billing
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseRevenueCat vs Raw Google Play Billing
RevenueCat 对比原生Google Play Billing
Phase 0: Intent
阶段0：用途
Use this skill when you are choosing between integrating RevenueCat or wiring Google Play Billing Library (PBL) directly, and you need to see which concerns disappear, which shift, and which still land on your team. The decision covers both the Android client and any server side infrastructure that supports subscriptions or one time purchases.
Typical questions this skill answers:
- If I adopt RevenueCat, what client code no longer exists in my app?
- What backend pieces (receipt verification, RTDN, state machine) does RevenueCat replace?
- What do I still own regardless of which path I pick?
- Is there a concern where raw PBL is the only option today?
当您在选择集成RevenueCat还是直接接入Google Play Billing Library（PBL）时，可使用此技能，它能帮您了解哪些事项无需再处理、哪些事项会转移，以及哪些仍需您的团队负责。该决策涵盖Android客户端以及任何支持订阅或一次性购买的服务器端基础设施。
此技能通常能解答以下问题：
- 如果采用RevenueCat，我的应用中哪些客户端代码可以删除？
- RevenueCat会替代哪些后端组件（收据验证、RTDN、状态机）？
- 无论选择哪种方案，哪些事项仍需我负责？
- 当前是否存在只能使用原生PBL的场景？
Phase 1: Locate the Concern
阶段1：定位关注点
Before reading the tables, identify what you are actually evaluating. Sort your requirement into one of these buckets and jump to the matching section:
| Bucket | Examples | Go to |
|---|---|---|
| Client purchase plumbing | BillingClient, listeners, acknowledgement, consumption | Client side table |
| Server purchase truth | Token validation, RTDN, entitlement state machine | Server side table |
| Out of scope for either | Auth, your user DB, paywall UI, push | Your responsibility table |
If the concern is split (for example, RevenueCat verifies the token but you still need to gate premium content on your API), you own the integration glue even though the verification itself is handled.
在查看表格之前，请先明确您实际评估的内容。将您的需求归入以下类别之一，然后跳转到对应的章节：
| 类别 | 示例 | 跳转至 |
|---|---|---|
| 客户端购买流程 | BillingClient、监听器、确认、消耗 | 客户端表格 |
| 服务器端购买真实性 | 令牌验证、RTDN、权益状态机 | 服务器端表格 |
| 两者均不涉及的范围 | 认证、用户数据库、付费墙UI、推送 | 您需负责的表格 |
如果关注点是拆分的（例如，RevenueCat负责验证令牌，但您仍需在API中限制付费内容访问），那么即使验证本身由RevenueCat处理，您仍需负责集成衔接工作。
Phase 2: Side by Side Reference
阶段2：对比参考
Client side
客户端
| Concern | Raw PBL | RevenueCat |
|---|---|---|
| BillingClient setup and configuration | You write | Handled internally |
| Connection lifecycle and reconnection | You write | Handled internally |
| PurchasesUpdatedListener | You write | Replaced by purchase callbacks |
| queryProductDetailsAsync() | You write | Replaced by awaitOfferings() / awaitGetProducts() |
| launchBillingFlow() | You write | Called internally by awaitPurchase() |
| Acknowledgement after purchase | You write | Handled automatically |
| Consumption of consumables | You write | Handled automatically (mark product as consumable in dashboard) |
| queryPurchasesAsync() on launch | You write | Handled internally on connection |
| Retry logic for transient errors | You write | Handled internally by SDK |
| BillingResponseCode handling | You write | Abstracted to PurchasesErrorCode |
| In-app payment recovery messages | You write | Automatic (showInAppMessagesAutomatically = true) |
| Subscription option selection for offers | You write | defaultOption selected automatically |
| 关注点 | 原生PBL | RevenueCat |
|---|---|---|
| BillingClient的设置与配置 | 需自行编写 | 内部处理 |
| 连接生命周期与重连 | 需自行编写 | 内部处理 |
| PurchasesUpdatedListener | 需自行编写 | 由购买回调替代 |
| queryProductDetailsAsync() | 需自行编写 | 由awaitOfferings() / awaitGetProducts()替代 |
| launchBillingFlow() | 需自行编写 | 由awaitPurchase()内部调用 |
| 购买后的确认操作 | 需自行编写 | 自动处理 |
| 消耗型商品的消耗 | 需自行编写 | 自动处理（在控制台中将商品标记为消耗型） |
| 启动时调用queryPurchasesAsync() | 需自行编写 | 连接时内部处理 |
| 临时错误的重试逻辑 | 需自行编写 | 由SDK内部处理 |
| BillingResponseCode处理 | 需自行编写 | 抽象为PurchasesErrorCode |
| 应用内支付恢复消息 | 需自行编写 | 自动显示（设置showInAppMessagesAutomatically = true） |
| 优惠订阅选项选择 | 需自行编写 | 自动选择defaultOption |
Server side
服务器端
| Concern | Raw PBL | RevenueCat |
|---|---|---|
| Google Play Developer API integration | You build | RevenueCat backend |
| Service account credential management | You manage | Configured once in RC dashboard |
| Receipt verification on every purchase | You build | Automatic |
| Purchase token validation and deduplication | You build | RevenueCat backend |
| linkedPurchaseToken chain traversal | You build | RevenueCat backend |
| RTDN processing and dispatch | You build | RevenueCat processes, sends webhooks |
| Cloud Pub/Sub setup | You set up | Not needed |
| Subscription state machine on backend | You build | CustomerInfo computed by RC |
| Entitlement computation across 7 states | You build | isActive computed by RC |
| Grace period / account hold tracking | You build | billingIssueDetectedAt |
| Cancellation with access-until-expiry logic | You build | isActive + unsubscribeDetectedAt |
| Price cohort tracking | You build | RC backend handles |
| Product-to-entitlement mapping | You build | Configured in RC dashboard |
| 关注点 | 原生PBL | RevenueCat |
|---|---|---|
| Google Play Developer API集成 | 需自行构建 | 由RevenueCat后端处理 |
| 服务账号凭证管理 | 需自行管理 | 在RC控制台中配置一次即可 |
| 每次购买的收据验证 | 需自行构建 | 自动处理 |
| 购买令牌验证与去重 | 需自行构建 | 由RevenueCat后端处理 |
| linkedPurchaseToken链遍历 | 需自行构建 | 由RevenueCat后端处理 |
| RTDN处理与分发 | 需自行构建 | RevenueCat处理并发送webhooks |
| Cloud Pub/Sub设置 | 需自行搭建 | 无需设置 |
| 后端订阅状态机 | 需自行构建 | 由RC计算生成CustomerInfo |
| 7种状态下的权益计算 | 需自行构建 | 由RC计算生成isActive |
| 宽限期/账户暂停跟踪 | 需自行构建 | 由billingIssueDetectedAt跟踪 |
| 保留访问权限至到期日的取消逻辑 | 需自行构建 | 由isActive + unsubscribeDetectedAt实现 |
| 价格群组跟踪 | 需自行构建 | 由RC后端处理 |
| 商品到权益的映射 | 需自行构建 | 在RC控制台中配置 |
What remains your responsibility either way
无论选择哪种方案，仍需您负责的事项
| Concern | Notes |
|---|---|
| User authentication system | You bring your own; pass user ID to RC |
| Your own database of users | RC is not your primary user database |
| Premium content server side | Verify via RC REST API or webhooks |
| Webhook receiver endpoint | You build; RC sends, you receive |
| Play Console product creation | Still done in Play Console |
| Subscription deferral | Direct Google Play API call |
| Subscription revocation | Direct Google Play API call |
| Alternative billing programs | Limited RC support; may need raw PBL |
| App UI (paywalls, onboarding) | You build (RC Paywalls UI optional) |
| Push notifications for payment issues | You build on top of webhook events |
| 关注点 | 说明 |
|---|---|
| 用户认证系统 | 需自行提供；将用户ID传递给RC |
| 自有用户数据库 | RC并非您的主要用户数据库 |
| 服务器端付费内容 | 通过RC REST API或webhooks进行验证 |
| Webhook接收端点 | 需自行构建；RC发送请求，您负责接收 |
| Play Console商品创建 | 仍需在Play Console中完成 |
| 订阅延期 | 直接调用Google Play API |
| 订阅撤销 | 直接调用Google Play API |
| 替代计费方案 | RC支持有限；可能需要使用原生PBL |
| 应用UI（付费墙、引导流程） | 需自行构建（可选使用RC Paywalls UI） |
| 支付问题推送通知 | 基于webhook事件自行构建 |
Phase 3: Recommendation Heuristic
阶段3：决策启发规则
Use these rules to convert the tables into a decision:
- If your app needs subscription deferral, subscription revocation, or an alternative billing program that RevenueCat does not yet cover, plan to keep a raw PBL path for those specific calls regardless of your main choice.
- If you would otherwise build a receipt verification service, an RTDN pipeline, and a subscription state machine from scratch, the server side table lists at least eight concerns that RevenueCat removes. Choose RevenueCat unless you have a concrete reason to own that stack.
- If you already have a mature billing backend with verified tokens and tested state handling, the gain is smaller. Weigh it against RevenueCat's client side simplifications and dashboard driven catalog.
- Always confirm the "remains your responsibility" row items are staffed. RevenueCat does not replace your auth, your user database, your paywall UI, or your premium content gate. Passing and verifying entitlements server side via the REST API or webhooks is still on you.
appUserID - When in doubt, map every requirement to a row in one of the three tables. Anything that lands in the "remains your responsibility" table costs the same under either option and should not drive the decision.
Quick gate:
text
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使用以下规则，将表格信息转化为决策：
- 如果您的应用需要订阅延期、订阅撤销，或者RevenueCat尚未支持的替代计费方案，无论您的主要选择是什么，都需为这些特定调用保留原生PBL的接入路径。
- 如果您原本需要从头构建收据验证服务、RTDN管道和订阅状态机，服务器端表格中列出的至少8项事项都可由RevenueCat代劳。除非您有明确理由需要自主掌控这些架构，否则选择RevenueCat。
- 如果您已拥有成熟的计费后端，且令牌验证和状态处理均经过测试，那么使用RevenueCat的收益会较小。请权衡其客户端简化能力和控制台驱动的商品目录优势。
- 请务必确认“仍需您负责”部分的事项已有相应人员处理。RevenueCat不会替代您的认证系统、用户数据库、付费墙UI或付费内容权限控制。传递以及通过REST API或webhooks在服务器端验证权益仍需您自行完成。
appUserID - 如有疑问，请将每项需求对应到三个表格中的某一行。任何属于“仍需您负责”表格的事项，在两种方案下的成本相同，不应影响决策。
快速判断准则：
text
需要自定义RTDN管道？ -> 只有当您必须完全自主掌控时才选择原生PBL
需要延期或撤销订阅？ -> 为这些API调用保留原生PBL路径
需要快速上线？ -> 选择RevenueCat，之后再添加原生PBL的备选方案