rc-revenuecat-vs-raw-billing

RevenueCat と Raw Google Play Billing の比較

フェーズ 0：目的

RevenueCat を統合するか、Google Play Billing Library（PBL）を直接組み込むかを選ぶときに、どの懸念事項が解消され、どれが移り、どれが引き続きチームの担当となるのかを確認するには、このスキルを使用してください。この判断の対象は、Android クライアントと、サブスクリプションまたは買い切り型の購入を支えるサーバー側インフラストラクチャの両方です。

このスキルでは、次のようなよくある質問に回答します。

• RevenueCat を導入すると、アプリ内のどのクライアントコードが不要になりますか？
• RevenueCat によって、バックエンドのどの要素（レシート検証、RTDN、状態マシン）が置き換えられますか？
• どちらの方法を選んでも、自分たちで担当する必要があるのは何ですか？
• 現時点で Raw PBL しか選択肢がない懸念事項はありますか？

フェーズ 1：対象の懸念事項を特定する

表を読む前に、実際に評価している内容を特定してください。要件を次のいずれかのカテゴリに分類し、該当するセクションに進んでください。

カテゴリ	例	参照先
クライアント側の購入処理	BillingClient、リスナー、承認、消費	クライアント側の表
サーバー側の購入情報	トークンの検証、RTDN、エンタイトルメントの状態マシン	サーバー側の表
どちらの対象範囲にも含まれないもの	認証、ユーザーデータベース、ペイウォール UI、プッシュ通知	自分たちの担当範囲の表

懸念事項が複数のカテゴリにまたがる場合（たとえば、RevenueCat がトークンを検証する一方で、API でプレミアムコンテンツへのアクセスを制御する必要がある場合）、検証自体が処理されていても、統合部分は自分たちで担当します。

フェーズ 2：比較リファレンス

クライアント側

懸念事項	Raw PBL	RevenueCat
BillingClient のセットアップと構成	自分で記述	内部で処理
接続のライフサイクルと再接続	自分で記述	内部で処理
PurchasesUpdatedListener	自分で記述	購入コールバックに置き換え
queryProductDetailsAsync()	自分で記述	awaitOfferings() / awaitGetProducts() に置き換え
launchBillingFlow()	自分で記述	awaitPurchase() 内部で呼び出し
購入後の承認	自分で記述	自動で処理
消耗品の消費	自分で記述	自動で処理（ダッシュボードで商品を消耗品として設定）
起動時の queryPurchasesAsync()	自分で記述	接続時に内部で処理
一時的なエラーへの再試行ロジック	自分で記述	SDK 内部で処理
BillingResponseCode の処理	自分で記述	PurchasesErrorCode に抽象化
アプリ内決済の回復メッセージ	自分で記述	自動（showInAppMessagesAutomatically = true）
オファーのサブスクリプションオプションの選択	自分で記述	defaultOption を自動選択

サーバー側

懸念事項	Raw PBL	RevenueCat
Google Play Developer API の統合	自分で構築	RevenueCat バックエンド
サービスアカウントの認証情報の管理	自分で管理	RC ダッシュボードで一度設定
購入ごとのレシート検証	自分で構築	自動
購入トークンの検証と重複排除	自分で構築	RevenueCat バックエンド
linkedPurchaseToken チェーンのたどり	自分で構築	RevenueCat バックエンド
RTDN の処理とディスパッチ	自分で構築	RevenueCat が処理し、ウェブフックを送信
Cloud Pub/Sub のセットアップ	自分でセットアップ	不要
バックエンドのサブスクリプション状態マシン	自分で構築	CustomerInfo を RC が算出
7 つの状態にまたがるエンタイトルメントの算出	自分で構築	isActive を RC が算出
猶予期間／アカウント保留の追跡	自分で構築	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 が不要にする項目が少なくとも 8 つ記載されています。そのスタックを自社で管理する具体的な理由がない限り、RevenueCat を選択してください。
3. 検証済みトークンとテスト済みの状態管理を備えた成熟した課金バックエンドがすでにある場合、得られる利点は小さくなります。RevenueCat によるクライアント側の簡素化や、ダッシュボード主導のカタログと比較して検討してください。
4. 「引き続きお客様の責任となる事項」の各項目を担当する人員が確保されていることを必ず確認してください。RevenueCat は、認証、ユーザーデータベース、ペイウォール UI、プレミアムコンテンツへのアクセス制御を代替しません。appUserID を渡し、REST API または Webhook を介してサーバー側でエンタイトルメントを検証することも、引き続きお客様の責任です。
5. 判断に迷った場合は、すべての要件を 3 つの表のいずれかの項目に当てはめてください。「引き続きお客様の責任となる事項」の表に該当するものは、どちらの選択肢でも同じコストがかかるため、判断材料にすべきではありません。

簡易チェック：

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

参考資料

• 章の全文