日本の代替決済の返金はどちらのストアでも開発者の仕事に。しかも1件ごとに Apple または Google への報告が必要です

日本の代替決済の返金は、いまや iPhone でも Android でも開発者自身の仕事です。Apple は2025年12月に iOS 26.2 で日本向けに代替決済処理を解禁し、Google Play の決済選択プログラムも2026年9月30日に日本のユーザー向けに始まりました。両ストアの取引条件は同じです。決済を自社で受けられる代わりに、返金、サポート対応、チャージバックもついてきます。多くのチームが見落としているのは事務手続きです。認めた返金は1件残らず、販売を許可してくれたストアに報告しなければなりません。

日本で何が、いつ変わったのか

スマホソフトウェア競争促進法（MSCA）は、2025年12月に指定事業者に対して全面施行され、Apple と Google もその対象です。Google は、対応にあたって公正取引委員会と18か月にわたり協議したとしています。Apple も同じ週に変更を実施しました。以下の日付は、両社自身のページに基づいています。

どちらのストアも、自社の決済をなくすことは認めていません。Apple は、代替手段を提供する場合でも In-App Purchase を引き続き利用可能にするよう求めています。Google は、Google Play Billing を自社の決済手段やウェブリンクと並べて提示するよう求めています。1つのアプリに2つの決済、そして2つの異なる返金窓口があるわけです。

日本の代替決済の返金は誰が対応するのか

簡単に言えば、ストアが処理した購入の返金はストアが対応し、それ以外は開発者が対応します。Apple In-App Purchase で支払った購入者は、引き続き Apple に返金を求められます。自社の決済代行業者経由で支払った購入者は、それができません。

Apple の説明

Apple の日本向けページの記述は明快です。代替決済による購入については、Apple は返金、購入履歴、サブスクリプション管理などの問題でユーザーを支援できず、開発者がユーザーと直接対応する責任を負います。また、決済処理、解約、返金に関する法令の遵守も開発者の責任とされています。決済サービスプロバイダは PCI Level 1 に準拠し、異議申し立て、サブスクリプション管理、返金をカバーするカスタマーサービス体制を運用していなければなりません。

Google の説明

Google の決済選択プログラムのルールには、3つの義務が明記されています。Play 外で取引を完了したユーザーに返金手段を提供すること。ただし、購入前に返金不可であることをユーザーに明示していた場合は除きます。それらの購入についてカスタマーサポートを提供すること。そして、不正な取引に異議を申し立てる手段を決済システムでユーザーに提供することです。さらに Google は、注文履歴の確認、サブスクリプションの管理、返金リクエストの開始ができるリンクの提供も求めています。

2つの証拠提出フローはここには存在しない

ストア決済で証拠の提出を求められる返金フローは2つだけです。消費データの送信に12時間が与えられる Apple の CONSUMPTION_REQUEST と、24時間が与えられる Google Play の orders.reviewrefund によるチャージバック審査です。どちらも、ストアが代金を受け取ったからこそ存在する仕組みです。自社の決済代行業者で支払われた購入では、どちらも発生しません。日本の購入者がその請求に異議を申し立てた場合、案件は決済代行業者と購入者の銀行の間で処理され、銀行の判断が最終となります。

Apple や Google に返金を報告する方法

返金を認めるのは仕事の半分にすぎません。どちらのストアも代替決済から手数料を取るため、返金された金額も把握したいと考えています。

Apple の返金明細

External Purchase Server API では、返金はタイプが REFUND の独立した明細行として扱われます。返金対象の取引、返金を完了した日付、報告通貨のミリ単位による税込みと税抜きの金額、そして Apple がすべての返金と restatement を反映したものと説明する純額が記載されます。Apple の明細ページには、異議申し立てに関わる重要な一文があります。チャージバックは返金として報告すること、です。

明細を誤った場合、Apple は訂正を求めます。同じ lineItemId を restatement を true にして再送すると、Apple は最新版のみを採用します。誤って送信した明細は、さらに erroneouslySubmitted を true にすることで取り消せます。

Google の返金 API 呼び出し

Google Play では、販売時に報告した externalTransactionId に対して refundexternaltransaction を呼び出します。全額返金は残額全体が対象です。一部返金には、一意の refundId と、返金した税抜き金額が必要です。サブスクリプションの場合、Google は返金対象となる個々の更新の ID を求めるため、3回課金されたサブスクリプションを返金するには3回の個別の返金呼び出しが必要になります。作成と返金のエンドポイントは、1分あたり1,200クエリの上限を共有しています。

日本の代替決済で実際にいくら節約できるのか

見出しどおりの節約額は多くのチームの予想より小さく、返金コストがさらにそれを削ります。以下は Apple が公表している日本向けの料率です。

標準的なアプリ内販売の場合、自社の決済代行業者に切り替えることで節約できるのは、顧客が支払う価格の5ポイントです。そして決済代行業者の手数料は、その5ポイントの中から支払うことになります。Google の決済選択プログラムの料率は、商品の種類とインストールの時期によって段階的に設定されています。アプリ内の代替決済について、ヘルプページでは自動更新サブスクリプションが10%、その他の購入は新規インストールか既存インストールかによって20%または25%とされており、対象となる開発者は年間収益の最初の $1M について10%が適用されます。

これまでストアが負担していたコスト

• 認めた返金：代金の全額が決済代行業者の残高から戻され、返金にかかる決済代行業者の手数料もすべて自社負担です。
• チャージバック：決済代行業者の異議申し立て手数料に加え、銀行向けの証拠をまとめる時間がかかります。先に勝つべきストアの審査はありません。
• カスタマーサポート：注文履歴、サブスクリプション、返金に関する質問に日本語で答えるスタッフやツールです。こうした購入者については、Apple も Google ももう対応しません。
• 報告：Apple への月次レポートと、すべての売上と返金から24時間以内の Google への API 呼び出しを実装するエンジニアリング作業です。

どの返金でも取り戻せないコスト

これらはもともとストアの問題ではなく、どちらにしても自社の負担です。購入者が利用した機能を支えるコンピューティング、そのリクエストによる API 呼び出し、作成したコンテンツの保存、そしてその販売についてクリエイターやパートナーに支払うべき報酬です。In-App Purchase であれば、CONSUMPTION_REQUEST によって、購入者が支払った分を消費したことを少なくとも Apple に示せます。自社の決済代行業者の場合、その主張をする相手は銀行です。しかもそれは、購入者が返金を求めるのではなく異議申し立てを行った場合に限られます。

若年層の購入者に関するルール

返金リスクが最も高いのは子どもが支払う場合で、Apple の日本向けルールはそれを前提に作られています。キッズカテゴリのアプリは、代替決済フローの前にペアレンタルゲートを置く必要があり、ウェブサイトでの購入は提供できません。その他のアプリは、保護者による購入管理機能に対応しなければなりません。13歳未満のユーザーは、ペアレンタルゲートを経たうえで、アプリ内の代替決済処理のみ利用できます。13歳から17歳のユーザーは、どちらの方法も利用できますが、いずれもペアレンタルゲートが必要です。

日本で代替決済を有効にする前のチェックリスト

• 日本語で返金ポリシーを作成し、購入者が支払う前にリンクを示しましょう。Google Play では、返金不可の販売は事前に開示しなければなりません。
• 注文履歴、サブスクリプション管理、返金リクエストのためのページを用意し、アプリからリンクしましょう。
• 決済代行業者が PCI Level 1 に準拠し、異議申し立て、返金、サブスクリプション変更に対応できることを確認しましょう。
• すべての売上、更新、返金を、各ストアが必要とする ID とともに記録しましょう。Apple は lineItemId、Google は externalTransactionId です。
• Apple の返金とチャージバックは月次レポートで報告し、Google への返金はサブスクリプション単位ではなく更新単位で送信しましょう。
• アカウントごとの利用記録を残しておきましょう。自社の決済代行業者では、それを見せる相手はストアではなく銀行だからです。
• Google の日本向け外部決済プログラムに参加している場合は、2027年3月31日までに決済選択プログラムへの移行を計画しましょう。