アプリ内課金(IAP)に関する新機能その1 〜App Storeサーバにおける新機能〜 WWDC2020

Session概要

iPhone、iPad、Mac、およびApple Watchのアプリ向けの優れたアプリ内課金体験を作り上げましょう。返金を管理し、新しいApp Storeサーバの通知を組み込み、受領書とサーバ通知の使用方法を理解してサブスクライバーのステータスを管理する方法について。
また、Apple Watch、家族間共有、SKOverlay、SKAdNetworkなどでのアプリ内課金を含む、StoreKitの最新のアップデート内容についても紹介します

https://developer.apple.com/videos/play/wwdc2020/10661/

IAPのApp Store サーバにおける新機能

返金や返金された取引をどのように処理するか

  • 返金処理は重要であるが、影響があるのは取引の中のごく一部で、適切な返金管理でさらに割合を減らすことが可能
  • 返金シナリオ
    1. ユーザがアプリでコンテンツを購入する
    2. ユーザが購入をミスし、ユーザがAppleのサポートに問い合わせる
    3. Appleでの審査の結果、返金が行われる
    4. 返金されたがアプリ内で購入した製品がアプリ内に残っていたため、ユーザがアプリ開発者に問い合わせる
    5. Appleの返金を把握していなければ、アプリ開発者側はどのように対処すべきか判断しにくい
  • Appleがユーザに返金したか確認することができれば、容易に適切な対象が可能となる
    • 例えば、アプリ内が購入した「ジェム」などの製品をユーザが保持したままとするか、没収するのか
  • 上記から、 Appleは返金の新しい管理方法を追加した
    • 適切な返金管理により、ユーザとの問題を迅速に解決することや、アプリ内経済を管理し、ユーザがより公平に使用することが可能となる
    • 新しい管理方法は、具体的にはApp Storeサーバ通知の提供で、返金通知(Refund notifications)です

IAPにおける返金シナリオ

なぜApp Storeサーバ通知にしたか?

  • 開発者がAppleに情報を要求せずに済むから
  • JSON POSTでステータス更新を直ちに通知、開発者からHTTP OKが返ってこなければ3回までリトライする
  • 自動更新サブスクリプションでApp Storeサーバ通知を受け取っているなら、少ない追加作業で新しい返金通知が受け取れるようになる
  • 記録を更新できるよう、キャンセルされた取引を含む更新されたレシートが送られる

App Storeサーバ通知を受け取る方法

  1. App Store Connectで希望する通知エンドポイントを設定する
  2. エンドポイントが開発者向けドキュメントのApp Transport Securityの要件を診対しているか確認する
  3. これにより通知の受け取りが可能

返金通知の詳細

  • 消耗型、非消耗型、非更新サブスクリプションで返金があれば、ユーザに返金後 Appleからこの通知が送られる
    • この通知により、返金に対して迅速な対応が可能になる
    • この通知の導入はプライバシーフレンドリーな形となっており、ユーザの情報は提供せず購入に関する情報のみ提供する
  • 通知を受け取る際のペイロードで注意すべき点
    • どの取引が返金されたかがわかる元の取引ID
    • 返金日時がわかるキャンセル日
    • キャンセル理由:0 or 1で、1ならアプリ内の問題によりユーザが返金を求めたことを示す
    • bid(bundle id), product_id:どのアプリと製品に関する通知かを特定できる
    • これらはすべてApp Storeサーバ通知ペイロード内の unified_receiptオブジェクトの最新レシートセクションにある
      • ただし、bidのみペイロードの1番上にある
    • password: アプリの共有鍵でApp Store Connectで見つけることができ、ペイロードがAppleからキたもので信頼できることを確認可能
  • ペイロードのレスポンスの詳細についてはこちら

コンテンツタイプによる返金の対処

  • アプリ内メッセージや返金された購入へのアクセス制限に使用可能
  • App Storeサーバからのサーバ間通知なので、クロスプラットフォームに対応可能

App Storeサーバ通知受け取り後のアクション

サブスクリプションを管理しやすくする方法

サブスクリプションのライフサイクルにおける主要イベント

  • 新規登録者の獲得
  • 自動更新
  • 自動更新の有効化と無効化
  • アップグレードとダウングレード
  • キャンセル

サブスクリプションのタイムライン(シナリオ)

  • ユーザが登録すると、Appleが登録期間と固定の自動更新期間を設定する
  • 最初の登録期間であまり利用しないと感じたユーザが自動更新をオフにしたが、少し後に更新を再度オンにしたとする
  • 更新日を迎えるが請求不備で更新に失敗
    • この時点では、請求リトライ期間の間は自動更新を試み、猶予期間も設けている
  • 猶予期間で登録が更新され、更新期間がそのままとなる

サブスクリプションのタイムライン
  • ユーザが登録に満足したとして、サブスクリプションプランのアップグレードを行えば、自動更新期間がアップグレードした日から再度設定し直され更新される
  • ユーザが元のサブスクリプションプランにダウングレードしたとする
    • ダウングレード処理は登録期間の最後に行われるため、次の自動更新日まではユーザはアップグレードしたプランのまま利用することができる

サブスクリプションにおけるイベントをどのように把握するか

  • App Storeサーバ通知のステータス更新が推奨
  • 開発者が情報を要求するのではなく、何かあればAppleから知らせる
    • 登録状況に変更があれば通知
    • 必要であれば、その時点での新しいレシートを提供
    • 拡張可能なので、登録者が増えても安心
  • App Storeサーバ通知のレスポンスにおける、サブスクリプションイベントに関わるデータ
    • auto_renew_product_id:次の自動更新が予定されており、この通知が関連する製品はどれかを確認する
    • notification_type:イベントのタイプがわかる
      • 例えば、DID_CHANGE_RENEWAL_STATUS:自動更新のオン・オフなど
      • 今年から新しい通知タイプ、DID_RENEWが追加された
        • 自動更新の成功後この通知が送られ、他の通知と同様更新されたサブスクリプションの特定に必要な情報が送られる
        • サブスクリプションに固有の識別子 original_transaction_idも含まれる 
        • 新しい登録期間に固有の識別子 transaction_id
        • expires_date_ms:失効日
        • auto_renew_product_id:自動更新された製品がわかるID
    • latest_receipt:ユーザのアップデートされたアプリレシートが得られる
    • latest_receipt_info:アプリの最新取引100件が含まれる
    • pending_renewal_info:ユーザがアプリ内で使用する各サブスクリプションの次の更新情報がわかる
      • この中にユーザがサブスクリプションオファーに申請したことを、更新前に通知され把握できるように promotional_offer_idが送られる
      • これはApp Storeサーバ通知以外では、レシートの検証で把握できる

サブスクリプションイベントのシナリオとApp Storeサーバ通知の関連

App Storeサーバ通知を活用したベストプラクティス

  • アップデートはApp Storeサーバ通知に頼り、レシートの検証をしなくてよい
    • ただし、下記のケースでレシートの検証が必要
      • サーバが停止した場合、次にユーザがオンラインになったときにレシートの検証を行いアップデートの抜けがないか状態を確認可能
      • レシートの検証を使用することでユーザの権限をただちに確認可能
      • 自動更新の成功確認
  • サブスクリプションの自動更新のダブルチェック
    • App Storeサーバ通知の DID_RENEW通知を追加で受け取るようにする
    • サブスクリプションの失効直後にレシートの検証の呼び出しを予約し、予定通りDID_RENEW通知を受け取ればキャンセルする
      • 遅延があれば、レシート検証で自動更新を確認する

App Storeサブスクリプションの新機能

家族間共有

  • 1つの購入を最大5人の家族と共有可能となる
  • 家族間共有は自動更新サブスクリプション、フル機能解除の購入などの非消耗型これら2タイプで利用可能
  • どのアプリ内課金を共有するかユーザが選ぶ
  • 家族間共有はユーザエンゲージメントや維持の向上に役立つ

利用方法

  • App Store Connectで家族間共有を特定の製品でオンにする
  • ※一度オンにするとオフにはできない
  • ユーザは後からアプリの管理で共有をオフにすることも可能
  • 非消耗型では、設定で購入アイテムを共有をオンにすることで、すべての購入アイテムが家族と共有される

App Store Connectでの家族間共有の設定
非消耗型の共有設定

アプリ側で家族間共有をサポートするためにやること

  • IAP製品の購入者だけでなく、家族とも取引を作成することとなる
    • そのため、家族の誰かがアプリを開くとトランザクションキュー内での取引がそれぞれのデバイスで可能になる
  • それぞれにレシートがあり、latest_receipt_infoに共有取引が含まれる
  • 製品購入後の家族間共有は、家族全員に利用可能にするため復元が必要となる
  • ファミリー共有を有効にした後、共有可能な製品を購入すると、購入者本人のデバイスのトランザクションキューに取引を書き込み、さらに家族全員のデバイスでトランザクションキューに取引を書き込む
  • 新規購入者の場合、共有可能なサブスクリプションはデフォルトで家族と共有される
    • 非消耗型はiCloudで共有が有効になっていれば、共有可能な購入は共有される
    • ただし、家族で支払いを共有しアプリが非表示になっていない場合
  • 既存購入者の場合、共有可能なサブスクリプションを共有するには管理ページで選択が必要
    • 非消耗型の共有は、同じく3つの条件を満たし購入を復元し共有を有効にする必要がある
  • 家族全員のアクセスを管理するにはレシートを使用する
    • 最新のレシートはレシート検証かApp Storeサーバ通知から入手可能
  • ユーザがアプリを開くたびにデバイス上でレシートをリフレッシュし、各顧客のアクセスを確認可能

最新情報をチェックしよう!