Apple と Google の返金はストアごと。クロスプラットフォームのサブスクリプションは、ほかのすべての場所でアクセスを止める必要がある

あなたのサブスクライバーは Apple に支払い、同じ日の午後に Android アプリを開き、今は職場で Web サイトを使っています。そこへ Apple が返金を行います。Google Play は知りません。Web の課金システムも知りません。自社のサーバーがアクセスを止めない限り、返金済みのクロスプラットフォームのサブスクリプションは、アカウントデータベースを参照するすべての画面で使え続けます。ストアは自分の店舗の分しか返金しません。サブスクリプション全体が存在するのは、あなたのアカウントシステムの中だけです。だからこそ、それを終わらせられるのもそこだけです。

1 つのストアの返金では、クロスプラットフォームのサブスクリプションが終わらない理由

Apple はこの構成を明文で認めています。App Review Guideline 3.1.3(b)、Multiplatform Services は、複数のプラットフォームで提供されるアプリが、ほかのプラットフォームや Web サイトで取得したコンテンツ、サブスクリプション、機能へのアクセスをユーザーに認めてよいと定めています。ただし、それらがアプリ内でも App 内課金として提供されていることが条件です。

複数のアプリで 1 つのサブスクリプションを提供するための Apple のガイドは、実際の仕組みを説明しています。アクセスを付与するのは統合されたアカウントデータベースを持つあなたのサーバーで、各アプリはそこを参照します。同じガイドは、購入がほかのアプリに反映されないと、ユーザーが同じサービスに二重に支払うおそれがあるとも警告しています。

この設計には見落とされがちな帰結があります。利用権はあなたのデータベースにありますが、各ストアが把握しているのは自分のレシートだけです。Apple は iPhone での購入を返金してあなたのサーバーに知らせることはできますが、Android アプリや Web サイトには何も伝えられません。返金処理が iOS クライアントだけを更新するなら、顧客はお金を取り戻したうえで、ほかのすべての場所でサブスクリプションを使い続けます。

返金後にすべてのプラットフォームでアクセスを取り消す方法

すべてのストア購入を 1 つのアカウントに紐づける

難しいのは返金を特定の人物に対応づけることです。ストアごとに購入者の識別方法が異なるからです。どちらのストアにも、自社のアカウント ID を入れるフィールドがあります。すべての購入でそれを使ってください。

• Apple では、購入開始時に appAccountToken を設定します。これはあなたが生成する UUID です。App Store はトランザクション情報と更新情報で同じ UUID を返します。Apple によれば、同じ顧客に属するすべてのトランザクションで 1 つの値を使い回してかまいません。
• 顧客がアプリの外で購入した場合、たとえば App Store でオファーコードを引き換えた場合、そのトランザクションにはトークンがありません。Set App Account Token エンドポイントで付与できます。自動更新サブスクリプションでは、現在とそれ以降の更新に適用され、過去のトランザクションには適用されません。また、ファミリー共有で共有された購入には使えません。
• Google Play では、課金フローを開始するときに setObfuscatedAccountId で難読化したアカウント ID を渡します。上限は 64 文字です。Google は、メールアドレスなどの平文の個人データを含めると購入がブロックされるとし、暗号化か一方向ハッシュを推奨しています。

両方のストアを受信し、1 つの利用権に書き込む

Apple は、自動更新サブスクリプションを含むあらゆる種類の商品を返金するときに REFUND を送ります。顧客が申し立てた異議によって付与済みの返金を取り消すときは REFUND_REVERSED を送ります。Google Play では、Voided Purchases API が返金済みおよびチャージバック済みの購入を一覧にし、それぞれに対象の購入または更新を特定する orderId が付きます。Web の決済代行会社も独自の返金イベントを送ってきます。この 3 つはすべて同じハンドラーに届き、同じレコードを更新すべきです。

取り消すのは利用権であり、アカウントではない

返金で取り消されるのは購入であって、人ではありません。返金された購入に由来するアクセスを外し、そのうえでアカウントに残っているものを再計算します。顧客がほかのストアでも有効なサブスクリプションを持っていれば、そちらを通じてアクセスは維持されます。持っていなければ、各クライアントは次にサーバーを確認したときにプレミアム機能を失います。

同じ人が 2 つのストアで購読している場合

二重購読は、この問題のもう半分です。Android で購読した人が新しい iPhone に替え、サインインせずにもう一度購読する。これで同じサービスに二重に支払うことになり、そのうち 1 件はたいてい返金リクエストになります。Apple のコマースチームは、Apple Developer Forums で開発者の質問に答えて、端的にこう述べています。アプリのアカウントシステムには、別のプラットフォームでの重複購入を防ぐロジックを組み込むべきだ、と。

ペイウォールを表示する前にすべてのストアを確認する

ペイウォールの前にユーザーをサインインさせ、サーバー上でその人の有効な購入をすべて確認し、どれかがこのプラットフォームをカバーしていればオファーを表示しないようにします。この 1 つのチェックで、重複課金の大半を発生前に防げます。

すでに重複している場合、どちらの購入を返金すべきか

自分で管理できるほうを返金します。Google Play では Play Console から自分で返金でき、DEVELOPER_REQUESTED_STOP_PAYMENTS を指定した purchases.subscriptionsv2.cancel で次回の支払いを止められます。Web のサブスクリプションは全面的にあなたの判断で返金できます。App Store の返金は Apple が決めるので、重複が iPhone 側にある場合は顧客が Apple に申請します。アプリから StoreKit の返金リクエスト API でその申請画面を開けます。

一部のプラットフォームに届かない返金がもたらすコスト

返金額は最初の損失にすぎません。Apple の返金が Android アプリや Web サイトに伝わらなかった顧客は、あなたが費用を払って運用しているものを使い続けます。セッションごとにコンピューティングリソースが消費され、AI 機能は請求対象のサードパーティ API を呼び出し続けます。ファイルはストレージを占有し続け、アプリが再生数や利用量に応じてクリエイターに支払っているなら、その支払いも続きます。年額プランなら、もう 1 円も払っていないアカウントのために丸 1 年分の提供コストを負担することになりかねません。

銀行経由になると、さらに悪化します。2026 年 8 月 3 日以降の Google Play の注文について、Google はチャージバックが成立した場合、開発者が Play のサービス手数料を差し引いた購入代金と、金融機関が課すチャージバック手数料を負担するとしています。チャージバックは銀行側で確定します。チャージバックをしたのにアクセスが残っている顧客は、代金、手数料、提供コストを一度にあなたに負わせます。

クロスプラットフォームの利用も証拠になる

ストアからあなたの言い分を求められたときにも、プラットフォームをまたぐ 1 つのアカウントは役に立ちます。Apple の消費情報では、消耗型、非消耗型、自動更新されないサブスクリプションのうち、顧客がどれだけ消費したかを尋ねられます。自動更新サブスクリプションでは割合を送る必要はありません。Apple が経過時間から計算するからです。Google Play のチャージバック審査では最大 1,000 件の消費利用イベントを受け付け、各イベントに難読化したアカウント ID を付けられます。どの端末で発生したものであれ、1 つのアカウント ID の下に記録された利用は、提示できる利用実績です。

あなたの言い分を求められない返金

ほとんどの返金は、あなたの関与なしに決まります。Google Play は独自の返金フローにより 48 時間以内に購入を返金することがあります。ストアのサポートによる返金、無効化された購入、そして承認しなかった購入を Google が約 72 時間後に自動返金するものは、いずれも先に実行され、後から報告されます。これらについては、前述の取り消しロジックがやるべきことのすべてです。

証拠を求めるフローは 2 つだけです。Apple の CONSUMPTION_REQUEST では、消費情報を送るまでに 12 時間あります。Google Play のチャージバック審査では、PendingRefundReviewNotification から 24 時間以内に orders.reviewrefund で回答する必要があり、Google が記録するのは最初の呼び出しだけです。RefundHalt は、あなたがすでに収集し、アプリ間で同じアカウントをキーにしている利用データを使って、どちらにも期限内に回答します。

クロスプラットフォーム返金の簡単なチェックリスト

• Apple の購入には appAccountToken を、Google Play の購入には難読化したアカウント ID を設定する。
• オファーコードの引き換えで欠けている Apple のトークンは、Set App Account Token で補う。
• Apple の REFUND と REFUND_REVERSED、Google Play の無効化された購入、Web の返金を 1 つのハンドラーに集める。
• 購入ごとに購入元とともに保存し、有効なすべての購入からアクセスを算出する。
• どのプラットフォームでも、ペイウォールを表示する前にすべてのストアの購入を確認する。