受け取るその他の購入の詳細を必ず確認する必要があります。サーバーを使用して購入の詳細を確認することを強くおすすめします。使用できるサーバーがない場合は、安全性は低下しますがアプリ内で検証を実施することもできます。エンジニアリングすることによって確認ロジックを無効にしようとする攻撃者からアプリを保護できます。サーバーで購入の詳細を確認する方法は次のとおりです。サーバーに送信します。サーバーは、検証が成功したら購入をユーザーに関連付ける必要があります。アプリからトークンを取得したら、次の操作を行います。Purchases.subscriptions)。ID、トークン(購入トークン)を含めます。前回の購入を表していない一意の値であることを確認します。インスタンスのユーザーと購入トークンを関連付けます。フィールドを確認します。フィールドには、前の(元の)購入のトークンが含まれています。ユーザーがアプリ内アイテムを利用できるようになります。ユーザーは、ネットワークに未接続の状態でも、常時アプリを利用できる状況を望んでいます。ユーザーに対応していることを確認してください。アプリ内で購入の詳細を確認できます。内でデベロッパーのアプリに関連付けられた秘密鍵を使って、この署名を作成します。キーペアを生成します。メソッドを使用します。形式でエンコード済みのバイナリ内にあります。ライセンス付与に使う公開鍵と同じものです。キーペアのうちの公開鍵で署名を確認します。署名確認をすることで、不正変更またはなりすましのレスポンスを見破ることができます。アプリ内に購入検証ロジックをバンドルする必要があるため、この検証形式は完全に安全というわけではありません。エンジニアリングを受けると、このロジックは危険にさらされます。請求サービスのコードを難読化する必要があります。使用してアプリのコードを難読化することをおすすめします。構成ファイルに次の行を追加する必要があります。請求サービスのコードを難読化したら、アプリで購入の詳細を検証する準備が整ったことになります。データに署名したことを確認します。キャッシュを更新するまでに時間がかかることがあります。ユーザーがあるデバイスから購入した場合、使用している他のデバイスはすぐには更新されません。購入を最新の状態に保つユーザーが行った購入を把握できなくなることが考えられます。つのシナリオがあります。回限りのアイテムをユーザーが購入します。サーバーに送信します。サーバーが一時的に障害を起こします。アプリはサーバーがダウンしていることを認識すると、購入に問題があることをユーザーに通知します。サーバーへの送信を再試行し、サーバーが復元されるとすぐに購入を終了します。アプリがコンテンツを公開します。スマートフォンで定期購入を行います。サーバーに送信します。サーバーが購入トークンを検証します。アプリがコンテンツを公開します。タブレットに切り替えます。新しいデバイス上のアプリが更新された購入リストを問い合わせます。アプリが定期購入を認識し、タブレットからのアクセスを許可します。アカウントによる購入を返します。クエリ結果を保存します。このリストにはアクティブな定期購入のみが含まれます。アプリ内アイテムがこのリストに含まれている場合は、ユーザーがアクセスできるようにする必要があります。処理についての説明をご覧ください。オブジェクトのさまざまなメソッドを呼び出して、購入ステータスや時間など、アイテムに関する関連情報を表示できます。クラスのメソッドのリストをご覧ください。呼び出して、アプリが最後に停止してからユーザーが行った購入を復元できます。コードを利用するなど)。呼び出すことで、アプリが実行されていない間にユーザーが行ったすべての購入とクーポンの利用を確実に調べることができます。呼び出せばその購入を認識できます。アプリのキャッシュを使用します。渡してクエリ結果を処理します。オブジェクトを返します。期限切れの購入、キャンセルされた購入、消費済みの購入も対象です。使うようにしてください。ボタンと組み合わせてユーザーが購入リストを更新できるようにすることも可能です。メソッドをオーバーライドする方法を次のコードの例で示します。ネットワーク呼び出しを行うため、アプリユーザーへの請求が発生する可能性があります。次のステップユーザーにアイテムの購入を許可したら、アイテム固有のシナリオをカバーする方法を学びます。回限りのアイテム固有の機能を追加するをご覧ください。請求サービスを追加して特典アイテムをサポートするには、特典アイテム固有の機能を追加するをご覧ください。追加するをご覧ください。