開発者コンソール
ログイン
ログイン
開発者コンソール

アプリ内課金（IAP）について

アプリ内課金（IAP）について

アプリ内課金（IAP）APIを使用すると、デジタルコンテンツや定期購入型アイテムの表示、処理、アイテム付与までをアプリ内で行うことができます。Amazonでは、AndroidアプリとウェブアプリでIAP APIをサポートしています。このページでは、IAP APIの概要を紹介します。

IAPとは？

IAPを使用すると、アプリのユーザーが、ゲームの追加ライフや定期購入型のプレミアムコンテンツなど、さまざまな種類のデジタルアイテムをアプリ内で購入できるようになります。

たとえば、IAPの使用ケースとして次のようなシナリオが考えられます。

  • アプリ自体は無料としながら、高度なサービスや機能を有料とする「フリーミアム」モデルを作成する。
  • ゲーム体験を充実させるために、通貨、追加アクション、ライフなどのアイテムをユーザーが購入できるようにする。
  • ユーザーがコンテンツへのアクセス権限を購入したら、ボーナスステージやミニゲームの利用制限を解除（アンロック）する。
  • アプリ内で提供されるコンテンツをユーザーが定期購入できるようにする。

購入フロー、支払い処理、アプリへのレシートの提供、購入可能なコンテンツの権限の管理などの詳細は、IAP APIによって処理されます。そのような処理を行うコードを独自に作成する必要はありません。

IAPでのAmazonの役割

Amazonアプリストアは、IAP APIのワークフローの中で欠かせない役割を担っています。ユーザーがアイテムの購入を決定した時点から、購入レシートまたは購入失敗時のステータスコードがアプリに渡されるまでの購入ワークフローは、Amazonによって実行されます。購入ダイアログ、トランザクションのタイムアウトロジック、完了時のお礼のダイアログを開発者側で作成する必要はありません。このようなトランザクションは、すべてAmazonアプリストアで処理されます。

ユーザーが購入手続きを開始すると、Amazonアプリストアクライアントアプリが最前面に開き、Amazonのユーザーインターフェイスが表示されます。ここでトランザクションを完了できます。購入ワークフローの次のようなすべての要素に対応するユーザーインターフェイスがこのアプリで提供されます。

  • 購入可能アイテムを表示するロジック
  • 購入の実行
  • 前提条件またはエラー状況の処理

購入に失敗した場合は、関連するメッセージがAmazonアプリストアからユーザーに表示されます。アプリからはメッセージを表示しないでください。たとえば、有効なクレジットカードが登録されていない場合は、Amazonアプリストアにより、支払い情報の変更ページにリダイレクトされます。購入フローに関するユーザーへの確認画面やそのほかのインタースティシャルダイアログを、開発者が独自に表示することは避けてください。

次の表では、IAPの実装時に必要となる処理を、アプリ側で実装する必要があるものとAmazonアプリストアが提供するものに分けてまとめています。

処理内容
アプリ
Amazon
購入可能なIAPアイテムのカタログをユーザーに提示する。
購入可能な機能をアンロックする。
購入フローを管理する。
支払い処理を実行する。
Amazonプラットフォームと安全な通信を行う（支払い時のセキュリティ確保を含む）。
非消費型アイテムを確認し、購入レシートを検証する。
定期購入型アイテムを自動更新するときの支払いを管理する。
非消費型アイテムを取り消すときの支払いを管理する。
ユーザーにコンテンツを提供する前に、定期購入型アイテムと非消費型アイテムのレシートを検証する。
リモートで配信されるコンテンツをダウンロードする。
ダウンロードしたデジタルアイテムを表示して使用する。
ユーザーによる購入と消費型アイテムの増減をトラッキングする。

IAPのコンポーネント

IAPを初めて使用する場合は、次のコンポーネントについて理解しておく必要があります。これらのコンポーネントは、いずれもIAP機能を実装するときに使用されます。

名前 説明 テクニカルドキュメント
IAP API アプリ内課金（IAP）を実装してアイテムを付与するには、IAP APIを使用します。 Androidアプリ： アプリ内課金（IAP）の実装について
ウェブアプリ： ウェブアプリ向けアプリ内課金（IAP）APIについて
ウェブアプリの詳細については、ウェブアプリ開発についてを参照してください。
アプリ内課金（IAP）APIリファレンス IAP APIのリストと説明です。 Androidアプリ： Appstore SDK APIリファレンス
ウェブアプリ： ウェブアプリ用アプリ内課金（IAP）APIリファレンス
ウェブアプリの詳細については、ウェブアプリ開発についてを参照してください。
Amazonアプリストア 支払い処理、警告、アイテム付与などのバックエンド機能を処理します。 該当なし
App Tester アプリをAmazonアプリストアで公開する前にローカルでテストします。 アプリ内課金（IAP）のテストについて
レシート検証サービス（RVS） トランザクションのレシートの有効性を検証します。RVSは、サンドボックス環境と本番環境に対応しています。 アプリ内課金（IAP）アプリのレシート検証
ライブアプリテストサービス 特定のユーザーグループを対象に、本番環境でアプリのベータテストを行います。 ライブアプリテストについて

IAPのタイプ

IAPを実装するときは、アプリからユーザーに提供するアイテムのタイプを定義する必要があります。また、購入されたアイテムの配信方法を決定する必要もあります。このセクションでは、IAPでサポートされる購入のタイプについて簡単に紹介します。

購入可能なアイテムとして認められるものと認められないものについては、Developer Services Agreementを参照してください。

購入可能アイテムのタイプ

IAPでは、3つのタイプの購入可能アイテムを実装することができます。

  • 消費型アイテム： 購入後にアプリ内で使用されるもの。追加ライフ、追加アクション、ゲーム内で使用する通貨などがあります。複数回購入することが可能です。
  • 非消費型アイテム： 1回限りの購入で、アプリ内またはゲーム内の機能やコンテンツの利用制限を解除（アンロック）するもの。
  • 定期購入型アイテム： プレミアムコンテンツやプレミアム機能へのアクセスを一定期間提供するもの。

コンテンツタイプと配信フロー

IAPでは、基本的な提供フローとして、次の3つがサポートされています。

  • 即時利用可能なコンテンツ
  • 配信型のコンテンツ
  • 購入の保留

即時利用可能なコンテンツ

即時利用可能なコンテンツとは、購入と同時にアンロックされるか、ユーザーが使用できるようになるコンテンツを指します。このモデルでは、必要な要素がすべて最初からアプリに含まれているため、ユーザーがアイテムを購入するとすぐに使用できるようになります。このモデルは、消費型、非消費型、定期購入型のどのタイプの購入可能アイテムでも使用できます。

アプリには、各購入可能アイテムの一意の識別子（SKU）と、ユーザーにカタログを表示する機能、トランザクションの成功時に購入可能アイテムをアンロックするロジックを組み込む必要があります。

手順 コンポーネント タスク
手順1 アプリ アプリがIAPフローを開始します。アプリから、購入を管理するIAP APIを呼び出します。
手順2 IAP API IAP APIがユーザーとやり取りして購入を完了します。IAP APIからアプリに購入レシートが返されます。
手順3 アプリ アプリでレシートを使用して、購入されたローカルコンテンツをアンロックします。

配信型のコンテンツ

配信型のコンテンツを使用すると、新しいコンテンツをユーザーに提供できます。このモデルでは、アプリが新しいコンテンツをサーバーからダウンロードし、ユーザーが利用できるようにします。定期購入型アイテムは典型的な配信型コンテンツの例です。

アプリには、各購入可能アイテムの一意の識別子（SKU）と、ユーザーにカタログを表示する機能、トランザクションの成功時にコンテンツをダウンロードして保存し、ダウンロードしたコンテンツを利用可能にするロジックを組み込む必要があります。

手順 コンポーネント タスク
手順1 アプリ アプリがIAPフローを開始します。アプリから、購入を管理するIAP APIを呼び出します。
手順2 IAP API IAP APIがユーザーとやり取りして購入を完了します。IAP APIからアプリに購入レシートが返されます。
手順3 アプリ アプリからアプリサーバーにレシートを送信して、コンテンツの配信を開始します。
手順4 アプリサーバー アプリサーバーがユーザーに対してコンテンツを利用可能にします。

購入の保留

購入保留機能はユーザーにすぐ提供できるわけではありません。このモデルでは、ユーザーが購入を開始してからユーザーにアイテムを付与するまでに、手順を追加する必要があります。購入が保留の状態にある間は、ユーザーにアイテムは付与されません。このモデルでは、消費型アイテムと非消費型アイテムを使用できます。

購入の保留のフローが配信型のコンテンツのフローと異なるのは、アプリがアプリ作成時にenablePendingPurchases()を呼び出し、onPurchaseResponse()でPurchaseResponse.RequestStatus.PENDINGを受け取ってもユーザーにアイテムを付与しないという点です。

手順 コンポーネント タスク
手順1 アプリ アプリがIAPフローを開始します。アプリがenablePendingPurchases()とpurchase() APIを呼び出してトランザクションを開始します。
手順2 IAP API IAP APIがユーザーとやり取りして購入をリクエストします。IAP APIからアプリにPENDINGステータスが返されます。
手順3 IAP API ユーザーがトランザクションを承認すると、リアルタイム通知（RTN）またはgetPurchaseUpdates()を通じて、IAP APIからアプリに購入レシートが返されます。
手順4 アプリまたはアプリサーバー アプリまたはアプリサーバーがユーザーに対してコンテンツを利用可能にします。

購入保留機能を実装する方法の詳細については、購入保留機能の実装を参照してください。

返金

消費型アイテムと非消費型アイテムについて、返金をリクエストする正当な理由がある場合、ユーザーはAmazonウェブサイトのお問い合わせまたはヘルプから、Amazonカスタマーサービスに問い合わせることができます。

定期購入型アイテムの場合、ユーザーは自動更新を解除することによって、そのアイテムの定期購入をキャンセルできます。ただし、解除した時点で定期購入型アイテムがすぐにキャンセルされるわけではありません。支払い済みの定期購入期間が終わるまでは、引き続きその定期購入型アイテムにアクセスできます。ユーザーに正当な理由がある場合は、Amazonウェブサイトのお問い合わせまたはヘルプからAmazonカスタマーサービスに連絡し、日割り計算による返金をリクエストできます。

SKU

SKUは、個々の購入可能アイテムに割り当てられる一意の識別子です。SKUは、開発者（正確には、開発者ポータルに登録されている開発者アカウント）ごとに一意であり、最大150文字の任意の形式の文字列です。使用可能な文字は、a～z、A～Z、0～9、アンダースコア、ピリオド、ダッシュで、大文字と小文字が区別されます。購入可能アイテムとSKUは1対1で対応付けられます。アプリでは、PurchasingManagerヘルパークラスを通じてSKU値をクライアントに渡します。クライアントではSKUに基づいて、ユーザーが何を購入しようとしているかを識別し、それに応じて購入フローを管理します。

定義するすべての購入可能アイテムに、それぞれ一意のSKUを割り当てる必要があります。SKUは開発者アカウント全体で一意となるようにしてください。複数のアプリのSKUを申請するときも、全体で重複がないことを確認する必要があります。

SKUを使用できるようにするには、開発者ポータルでの構成が必要です。SKUの構成方法については、よくある質問の開発者ポータルのセクションを参照してください。

アプリの申請プロセス

IAPを組み込んだアプリの場合は、Amazonアプリストアに申請する前に、IAPアイテムを作成して申請する必要があります。Amazonアプリストアは、アプリとIAPアイテムの両方が申請されるまでアプリのテストを行いません。

IAPアイテムのカタログを作成して管理するには、開発者コンソールを使用します。単一のアプリ内課金（IAP）アイテムを作成および申請する方法を参照してください。

一度に複数のIAPアイテムを作成または変更することもできます。アプリ内課金（IAP）アイテムの一括申請用CSVファイルを参照してください。

アプリの申請後にIAPアイテムを追加または編集した場合は、新しいアイテムや変更したアイテムだけでなく、アプリ自体もAmazonアプリストアに再申請する必要があります。

Last updated: 2023年9月18日