App Store Connectサーバーでアプリ内購入を管理する
サーバーでのアプリ内購入の管理に関する最新のアップデートをご覧ください。サーバーを使用してステータスの変更を追跡し、払い戻しを処理し、サブスクライバーのステータスを管理する方法を探ります。ステータスとアプリ内購入トランザクションに関するAppStoreサーバーAPIについて学び、AppStoreサーバー通知が顧客ライフサイクルイベントの追跡にどのように役立つかを確認します。また、アプリ内購入のファミリー共有の管理、およびサンドボックス環境でのアプリ内購入のテストに対する最新の改善についても説明します。
Manage in-app purchases on your serverの内容を理解していく。
このWWDCセッションは、StoreKIT2で行われた購入行為を、アプリケーションとサーバーを使って連携することを、どのように実現するのかを説明しています。
この機能を実現するためには、別途サーバーが必要とな流様です。
このHPはサーバーをレンタルしているので、このセッションで紹介している内容を試せるかもしれません。
新しいキーワードとして、Apple Store Connectというものがある様です。
JSONフォーマットで定義されたレシートをどの様にアプリと連携するのか。
新しい技術がたくさん得られる上に、理解するために英語を聞かないといけない。
忙しいサラリーマン生活だけでは得られなかった知識が、
効率よく得られるのではないかと思います。
このセッションは、Apple Store Connectと自身のサーバーを接続する機能とわかりました。
まだ、Apple Debeloper Program に登録していないため、
このセッションは、APLリリース間際に勉強した方が良さそうです。
まだまだ初心者の自分としては、今回のセッションは、
サーバーと連携する方法により、よりリアルタイムにアプリの状態を更新できるということが
わかったというところまででしょうか。それではまた次のセッションへ移りたいと思います。
サーバーと、アプリ内購入を管理するためのサーバーを構築する方法
サーバーを持っている場合、App Storeサーバー通知を通じて、アプリ内購入のステータスが変更されたときにリアルタイムで通知することができる。
・App Storeの領収書を使用してアクセスを検証。
・App Store ServerAPIを使用してステータスを追跡。
・AppStoreサーバー通知を使用してステータスを受動的に追跡。
デバイスがオフラインの場合やアプリの外部でステータスが変更された場合でも、顧客がコンテンツにアクセスできるため、更新後も顧客がサブスクライブされているかどうか、またはゲームで購入したコインが払い戻されているかどうかがわかります。
App Storeサーバー通知を通じて、アプリ内購入のステータスが変更されたときにリアルタイムで通知することができます。
また、サーバーを使用していつでもオンデマンドでステータスを確認できます。
その購入に関する情報をサーバーに送信すると、transactionId、originalTransactionId、レシートなどを含め、サーバーと直接通信することで、サーバーからの購入を追跡できるようになりました。
領収書を使用してステータスを検証する。
現在、領収書は統一されたアプリの領収書形式になっています。
レシートのJSONバージョンを取得するには、アプリでデバイス上のレシート検証を行うか、サーバーについて説明しているため、サーバー間verifyReceiptエンドポイントを呼び出す必要があります。
さらに、StoreKit 2では、クライアント側でJWSまたはJSON Web署名形式の新しい署名付きトランザクションを導入しており、サーバーでも同じことを提供される。
署名されたトランザクションは、ピリオドで区切られた3つの文字列で構成されます。最初の文字列はbase64でエンコードされたJSONヘッダー、次にbase64でエンコードされたJSONペイロード、その後に署名が続きます。
トランザクションをデコードするために必要なことはすべてですペイロードをbase64でデコードします。これは、サーバー上で独自に実行できる簡単な操作です。
App Store ServerAPIを使用してステータスを追跡する。
ここで、JWT認証について説明します。
新しいAppStore Server APIはすべて、JSON Web Token（JWT）認証を利用します。
これは、サーバーとお客様の間の通信のセキュリティを強化するために選択されました。
このJWTを生成するには、App StoreConnectから秘密鍵をダウンロードする必要があります。
このプロセスにより、公開鍵がサーバーに自動的に登録されます。
次に、サーバーを呼び出す前に、ES256アルゴリズムを使用してトークンに署名する必要があります。
App Store Connectで秘密鍵を生成するには、[ユーザーとアクセス]ページに移動し、[鍵]タブにアクセスします。
アプリ内購入キーオプションを選択すると、次のようなページが表示されます。
キーを追加して名前を付けます。
ダウンロードできるのは1回だけなので、キーを安全な場所に保存し、キーIDをメモしておきます。
AppStoreサーバー通知を使用してステータスを受動的に追跡する。
Apple IDを取り直さないといけないのかなぁ
こんにちは、WWDCへようこそ。私はToriです。
サーバーに追加された新機能についてお話しし、すべてのアプリ内購入のステータスを追跡するための効果的なサーバーを実行するためのガイドラインを設定するのに役立つことをとてもうれしく思います。
それでは、すぐに飛び込みましょう。
このセッションは、アプリ内購入に焦点を当てた3セッションシリーズのパート2です。「MeetStoreKit2」や「顧客をサポートして払い戻しを処理する」をまだご覧になっていない場合は、このセッションの後で全体像を把握することをお勧めします。
このセッションでは、サーバーと、アプリ内購入を管理するためのサーバーを構築する方法に焦点を当てます。
このセッションを開始するために、最初にサーバーがあると便利な理由のいくつかについて説明しましょう。
サーバーを持つことはいくつかの理由で役立ちます、そしてアプリ内購入の場合、それらのほとんどはステータスの追跡を中心に展開します。
サーバーをお持ちの場合、App Storeサーバー通知を通じて、アプリ内購入のステータスが変更されたときにリアルタイムで通知することができます。
また、サーバーを使用していつでもオンデマンドでステータスを確認できます。
-サーバーへのAPI。サーバーがあると、検証できます
デバイスがオフラインの場合やアプリの外部でステータスが変更された場合でも、顧客がコンテンツにアクセスできるため、更新後も顧客がサブスクライブされているかどうか、またはゲームで購入したコインが払い戻されているかどうかがわかります。
すでにサーバーをお持ちの場合は、これらの理由のいくつかでサーバーをセットアップした可能性があります。
サーバーがなく、サーバーの構築を検討している場合は、コンテンツをより細かく制御できるため、これらを検討する必要があります。
サーバーをお持ちの場合でも、iPhone、iPad、またはアプリ内購入のあるその他のデバイスでストーリーが始まります。
その購入に関する情報をサーバーに送信すると、transactionId、originalTransactionId、レシートなどを含め、サーバーと直接通信することで、サーバーからの購入を追跡できるようになりました。
現在、これには、verifyReceiptなどのAPIまたはAppStoreサーバー通知などのフレームワークの使用が含まれます。
私たちはあなたのために私たちのサーバーとの統合をさらに良くしたいだけです。
それは私たちを今日のコンテンツにもたらします。
サーバー側で行われたすべての変更と、これらと統合してより優れた、より強力なサーバーを構築する方法を確認します。
まず、App Storeの領収書を使用してアクセスを検証し、App Store ServerAPIを使用してステータスを追跡します。次に、AppStoreサーバー通知を使用してステータスを受動的に追跡する方法について詳しく説明します。
また、これが家族の共有を管理するために何を意味するのか、サンドボックスでサーバーをテストする方法についても説明します。
領収書を使用してステータスを検証することから始めましょう。
現在、領収書は統一されたアプリの領収書形式になっています。
レシートのJSONバージョンを取得するには、アプリでデバイス上のレシート検証を行うか、サーバーについて説明しているため、サーバー間verifyReceiptエンドポイントを呼び出す必要があります。
サーバー間でCallをかけると、このデコードされたレシートに加えて、latest_receipt_infoセクションの新しいトランザクション、pending_renewal_infoセクションの今後の更新情報、およびlatest_receiptを取得します。
この領収書は膨大なものになる可能性があり、非消耗品であるかどうかに関係なく、アプリ全体からのトランザクションが含まれています。
消耗品、サブスクリプション、または非更新サブスクリプション。
これはあなたにたくさんの情報を提供しますが、それが多すぎるのではないかと思います。
さらに、StoreKit 2では、クライアント側でJWSまたはJSON Web署名形式の新しい署名付きトランザクションを導入しており、サーバーでも同じことを提供したいと考えています。
署名されたトランザクションを導入することにしたのはなぜですか？
アップルでは、セキュリティに関心を持っています。
JWSを使用してこれらのトランザクションに署名すると、署名と署名の検証を通じてセキュリティが向上します。
さらに、トランザクションはデコードと検証が簡単なので、それを実行できます私たちにCallすることなくあなたのサーバー上で。
これらの署名されたトランザクションを見てみましょう。
署名されたトランザクションは、ピリオドで区切られた3つの文字列で構成されます。最初の文字列はbase64でエンコードされたJSONヘッダー、次にbase64でエンコードされたJSONペイロード、その後に署名が続きます。
ヘッダーをbase64でデコードすると、使用した署名アルゴリズムとx5Cクレームが含まれます。
これには、署名を検証するために必要な証明書チェーンが含まれています。
署名の検証に少し戻ります。
次に、ペイロードをbase64でデコードすると、レシートJSONが表示されます。
つまり、トランザクションをデコードするために必要なことはすべてですペイロードをbase64でデコードします。
これは、サーバー上で独自に実行できる簡単な操作です。
デコードされたトランザクションを簡単に見てみましょう。
ちらっと見ると、一部のデータ型が以前の領収書の文字列から、数値やブール値などのより適切なデータ型に変更されていることに気付くかもしれません。
また、日付形式がエポックから1ミリ秒に短縮されていることにも注意してください。
また、いくつかの新しいフィールドを追加しました。
トランザクションが適用されるコンテンツタイプを示す「タイプ」というフィールドを追加しました。
「appAccountToken」というフィールドも追加しました。
購入時にこの値をStoreKitに提供する場合StoreKit 2アプリでは、サーバーに永続化して、各トランザクションで返します。
これは、新しく署名されたトランザクションだけでなく、各トランザクションの既存の統合アプリレシートでも返されます。
ここで呼びたい次の2つのフィールドは、実際には新しいものではなく、名前が変更されています。
cancel_dateとcancel_reasonの名前をrevocation_dateとrevocation_reasonに変更しました。
これにより、これらのフィールドの存在が、失効日時点でサービスを取り消す必要があることを明確に示しています。
これらの最後の2つのフィールドは新しく見えるかもしれませんが、実際には以前の領収書からのいくつかの情報を単純化したものです。
isTrialPeriod、isIntroOfferPeriod、promotionOfferIdentifier、offerCodeRefNameをofferTypeとofferIdentifierに結合しました。
OfferTypeは、顧客がこの期間に適用したオファーのタイプを示します。
1つはイントロオファー、
2つはサブスクリプションオファー、
3つはオファーコードです。
オファータイプが2または3の場合、プロモーションオファーIDまたはofferCodeRefNameのいずれかを含むオファー識別子フィールドにも値が表示されます。
ここで、署名されたトランザクション情報の署名部分の検証について説明します。署名の確認は、トランザクションがAppleからのものであり、信頼できるものであることを確認するためのオプションです。
トランザクションの内容のみを表示する場合は、この手順は必要ありません。
ただし、署名を確認するには、署名されたトランザクション情報のヘッダー部分にあるクレームを使用する必要があります。
algクレームを使用して、使用した署名アルゴリズムを確認し、x5cクレームの配列で証明書チェーンを使用します。
これら2つを取得したら、お気に入りの暗号化ライブラリを使用して、署名されたトランザクション情報の署名を確認できます。
これで、App Storeの領収書、または現在は署名済みのトランザクションの変更について説明します。
それでは、APIを使用してステータスを確認する方法に移りましょう。
そのため、署名されたトランザクションの有効性を検証したり、トランザクションをデコードしたりするために、今日のverifyReceiptのようなAPIは必要ありませんが、サーバー上で役立つAPIを構築したいと考えていました。
そのため、今年はWWDCでApp Store Server APIの新しいライブラリを導入します。
これにより、サーバーではこれまで利用できなかったいくつかの新機能が提供され、新しい署名済みトランザクションも利用されます。
そこで、今度は2つの新しいAPIについて説明します。サブスクリプションステータスAPIとアプリ内購入履歴APIです。
まず、サブスクリプションステータスAPIについて説明します。
サブスクリプションステータスAPIは、アプリのoriginalTransactionIdで示される、自動更新可能なサブスクリプションの最新のステータスを提供します。
このAPIを使用すると、サブスクライバーのステータスに関する簡単な回答を得ることができます。
1つの簡単なチェックで、サブスクリプションがアクティブであるか、期限切れであるか、猶予期間中であるか、または他の状態であるかをすばやく知ることができます。それを見てみましょう。
このAPIへのリクエストは単純で、URLにoriginalTransactionIdのみが必要です。このAPIからの応答には、顧客がアプリでサブスクライブしているすべてのサブスクリプションのステータスが含まれています。
SubscriptionGroupIdentifierによってグループ化されます。
各subscriptionGroupIdentifierについて、サブスクリプショングループ内の各originalTransactionIdのエントリとともに、最新のトランザクションのリストを提供します。
この配列の各エントリには、ステータス、originalTransactionId、signedTransactionInfo、signedRenewalInfoが含まれ、これらもJWS形式で署名されています。
ここで、そのステータスフィールドを詳しく見てみましょう。
ステータスフィールドには、サブスクリプションのステータスに関する簡単な回答が表示されるので、サブスクライバーのサービスのロックを解除するかどうかを知ることができます。
ステータスには5つの可能な値から始めます。
1は、サブスクリプションがアクティブであることを意味します。
2、サブスクリプションの有効期限が切れていることを意味します。
3、サブスクリプションが請求の再試行期間にあることを意味します。
4、サブスクリプションが猶予期間中であることを意味します。
5は、キャンセルまたはその他のイベントのためにサブスクリプションアクセスが取り消されたことを意味します。
ステータスフィールドを見ると、サブスクリプションに関する簡単な回答が得られます。
そのステータスの詳細については、署名されたトランザクション情報のペイロードと署名された更新情報のペイロードを確認できます。
署名されたRenewalInfoをデコードするには、ペイロード部分をbase64でデコードすることにより、署名されたトランザクション情報の場合と同じ手順に従います。
さらに、ヘッダーを使用して、同じ方法でsignedRenewalInfoの署名を確認できます。
デコードされると、次のようなものが表示されます。
更新情報には、今日のverifyReceiptの保留中の更新情報セクションで提供するものと同じフィールドが含まれています。
日付形式を1つだけ含めたり、該当する場合は一部のフィールドをブール値または数値にするなどの更新があります。
また、signedRenewalInfoに新しいフィールドofferTypeとofferIdentifierを追加します。これにより、顧客が次回の更新時にオファーを引き換える予定があるかどうかが通知されます。
サブスクリプションステータスAPIに加えて、すべてのトランザクションを取得する方法を提供したいと考えています。
今日のverifyReceiptのlatest_receipt_infoセクションで提供されているように、アプリに関連付けられています。
このため、アプリ内購入履歴APIも追加しています。
アプリ内購入履歴APIは、今日のverifyReceiptのlatest_receipt_infoセクションで受け取るのと同じように、アプリのすべてのトランザクションの履歴を提供します。
ここでの主な違いは、各トランザクションが新しい署名付きトランザクション情報形式になり、APIがページ化されてAppStoreから受信する応答のサイズを制御することです。
これに対する最初のリクエストは、サブスクリプションステータスAPIと同様に、非常に単純です。
リクエストを処理するには、originalTransactionIdのみが必要です。
応答では、アプリのApple IDやバンドルIDなどのアプリのメタデータと、新しい署名済みトランザクション情報形式でのアプリの最新の20トランザクションの配列を受け取ります。
リクエストごとに20の署名されたトランザクション情報を返します。
さらにトランザクションがある場合は、応答のhasMore値とリビジョン値を確認してください。
アプリに残っているトランザクションが多い場合、hasMoreはtrueになります。
この場合、次の20トランザクションを取得するために、クエリパラメータとしてリビジョントークンを渡して、別のリクエストを行います。
hasMoreがfalseになるまでこれを繰り返します。
それでは、ピボットして、すべてのApp Store ServerAPIがどのように機能するかについて話しましょう。
互いに一貫性があります。
これらはすべてJWT（またはJSON Webトークン）認証の背後にあり、新しい署名付きトランザクションをサポートし、JSON要求および応答形式を備えています。
そして何よりも、それらはすべて、リクエストでレシートと共有シークレットを要求するのではなく、リクエストで提供するoriginalTransactionIdをキーオフします。
ここで、JWT認証について説明します。
新しいAppStore Server APIはすべて、JSON Web Token（JWT）認証を利用します。
これは、サーバーとお客様の間の通信のセキュリティを強化するために選択されました。
このJWTを生成するには、App StoreConnectから秘密鍵をダウンロードする必要があります。
このプロセスにより、公開鍵がサーバーに自動的に登録されます。
次に、サーバーを呼び出す前に、ES256アルゴリズムを使用してトークンに署名する必要があります。
App Store Connectで秘密鍵を生成するには、[ユーザーとアクセス]ページに移動し、[鍵]タブにアクセスします。
アプリ内購入キーオプションを選択すると、次のようなページが表示されます。
キーを追加して名前を付けます。
ダウンロードできるのは1回だけなので、キーを安全な場所に保存し、キーIDをメモしておきます。
それでは、このJWTが実際にどのように見えるかを見てみましょう。
JWTは、ヘッダー、ペイロード、署名の3つの部分で構成されます。
ヘッダーには、キーIDを含める必要があります秘密鍵と署名に使用されるアルゴリズムの SHA 256ハッシュ（ES256）を使用した楕円曲線署名が必要です。
トークンのタイプ（この場合は常にJWT）も含めます。
ペイロードには発行者IDが含まれている必要があります。
この値は、App StoreConnectで見つけることができます。
トークンが発行された時刻と有効期限が切れる時刻を、エポックからの秒数で含めます。これらの2つの時間の差は1時間以内である必要があります。
常にappstoreconnect-v1であるオーディエンスを含めます。
ナンス、または1回限りの一意の文字列を生成する必要があります。
最後に、アプリのバンドル識別子を含める必要があります。
この情報をすべて取得したら、ES256アルゴリズムを使用してこのトークンの署名を実装するか、SHA256ハッシュを使用して楕円曲線署名を実装する必要があります。
先に進む前に、App Store ServerAPIの重要なポイントを確認しましょう。
まず、ステータスの決定とトランザクションの履歴の検索を分離しました。
これらは別個の機能であるためです。
次に、これらのAPIは、リクエストにoriginalTransactionIdのみを必要とします。
つまり、受信した署名済みトランザクションを取得できます。
アプリまたはサーバーからの応答のいずれかから、originalTransactionIdを含む関心のあるフィールドを保存してから、署名されたトランザクション情報を削除します。過去に領収書を使用するようにガイドしたので、署名されたトランザクションを保存する必要はもうありません。
これで、新しいApp Store ServerAPIを使用して顧客のステータスを確認する方法について説明します。
ここで、App Storeサーバーの通知を一貫性のあるものにする方法と、通知を使用してステータスを追跡する方法について説明します。
まず、AppStoreサーバーの通知を簡単に確認することから始めましょう。
AppStoreサーバーの通知について説明しました数年前から、なぜそれらが役立つのかを見てみましょう。
App Storeサーバー通知を使用すると、トランザクションの1つのステータスがAppStoreから直接変更されたときに通知を受け取ることができます。
通知を受け取ったら、顧客が電話でアプリを開かなくても、すぐにステータスを更新できます。
App Storeサーバー通知を使用すると、ステータスについて電話する必要もありません。何かが変わったときにお知らせします。
これらは、サーバーが利用できる最も強力なツールの1つです。
今年の私たちの目標は、App Storeのサーバーの通知にすることです私たちの新しいを利用することにより、さらに強力に、使いやすい署名付きトランザクション。
これに加えて、通知を更新して、1つのユーザーアクションに対して1つの通知のみが送信されるようにし、ペイロードを更新し、セキュリティを強化するためにJWSを使用してペイロード全体に署名します。
また、準備ができたらv2通知にオプトインして、しばらくの間既存の通知を送信し続けることもできます。
これは、v1通知用の現在の通知オファリングです。INITIAL_BUYからREVOKEまで、全部で11種類あります。
v2通知では、4つの通知タイプ（INITIAL_BUY、INTERACTIVE_RENEWAL、CANCEL、およびPRICE_INCREASE_CONSENT。ただし、SUBSCRIBED、OFFER_REDEEMED、EXPIRED、GRACE_PERIOD_EXPIRED、およびPRICE_INCREASEの5つの新しいタイプを追加しています。
新しい通知タイプに加えて、「サブステート」と呼ばれる新しいフィールドを通知に追加します。これは、より一般的な通知タイプを特定のユーザーアクションに絞り込むのに役立ちます。
現在、サブステートは、SUBSCRIBED、DID_CHANGE_RENEWAL_STATUS、DID_CHANGE_RENEWAL_PREFERENCES、OFFER_REDEEMED、EXPIRED、およびPRICE_INCREASEの6つのv2通知タイプに適用されます。
サブステートがこれらの通知タイプにどのように適用されるかの例をいくつか見てみましょう。
まず、SUBSCRIBED通知とそのサブステートについて説明します。顧客が初めて購入するとき、あなたはINITIAL_BUYのサブステートでSUBSCRIBEDを受け取ります。顧客が同じSKUまたは別のSKUに再サブスクライブすると、サブスクリプションが同じサブスクリプショングループ内にある限り、サブステートがRESUBSCRIBEのSUBSCRIBEDを受け取ります。
v1 App Storeサーバー通知に同等のタイプがない新しい通知タイプの1つは、OFFER_REDEEMED通知です。
そこで、この例を見てみたいと思います。
OFFER_REDEEMEDは、顧客がプロモーションオファーを引き換えるたびに受信されます。
顧客が初めての購入のオファーを引き換える場合、INITIAL_BUYのサブステートを持つOFFER_REDEEMEDを受け取ります。
顧客が同じ非アクティブなサブスクリプションに再サブスクライブするオファーを引き換えると、RESUBSCRIBEのサブステートを持つOFFER_REDEEMEDを受け取ります。
顧客がアクティブなサブスクリプションをアップグレードするオファーを引き換えると、UPGRADEのサブステートでOFFER_REDEEMEDを受け取ります。顧客がアクティブなサブスクリプションをダウングレードするオファーを引き換えると、サブステートがDOWNGRADEのOFFER_REDEEMEDを受け取ります。
さらに、顧客が同じ期間内にキャンセルした後、アクティブなサブスクリプションに再サブスクライブするオファーを引き換えた場合、AUTO_RENEW_ENABLEDのサブステートを持つOFFER_REDEEMEDを受け取ります。
それでは、EXPIREDを見てみましょう。
新しいEXPIRED通知タイプでは、顧客がVOLUNTARYのサブステートで自動更新を無効にした後、サブスクリプションの有効期限が切れるとEXPIREDを受け取ります。正常に回復せずに請求の再試行期間が終了したためにサブスクリプションが期限切れになった場合、BILLING_RETRYのサブステートでEXPIREDを受け取ります。さらに、顧客が値上げに同意しなかったためにサブスクリプションの有効期限が切れた場合、PRICE_INCREASEのサブステートでEXPIREDを受け取ります。
そのため、v2通知タイプとそれに該当するサブステートを組み合わせて、20を超えるさまざまな顧客ライフサイクルイベントをカバーするようになりました。
通知の種類を確認するだけで、購入で何が変更されたかを大まかに把握できますが、サブステートを確認すると、より詳細に説明したい場合に、より具体的な状態を取得するのに役立ちます。
それでは、新しいペイロードを簡単に見てみましょう。
v2通知の場合、通知の種類に関係なく、常に同じフィールドのセットが含まれます。通知タイプ、サブタイプ、通知バージョン（v2通知をサブスクライブした場合は2になります）、通知が適用される環境、バンドルID、アプリApple ID、バンドルバージョンなどのアプリメタデータ、影響を受けるアプリ内の最新のトランザクションを新しいsignedTransactionInfo形式で、アプリ内の最新の更新情報を新しいsignedRenewalInfo形式で。
これらの変更により、通知の解析が容易になり、新しい署名済みトランザクションを利用し、影響を受けるアプリ内購入に関する情報のみが含まれるため、通知の採用が容易になります。
先に述べたように、通知のセキュリティと信頼性を高めるために、ペイロード全体が署名されます。
今見たペイロードは読みやすさのために署名されていませんが、署名はトランザクションと更新情報に署名する方法と同様になりますJWS形式で。準備ができたら、v2通知にオプトインできるようにしてください。
このため、App Store Connectの通知URLにオプションを追加して、AppStoreサーバーの通知バージョンを選択できるようにします。
これを行うには、アプリのページに移動し、新しいAppStoreサーバー通知セクションまでスクロールします。
本番サーバーのURLを選択すると、バージョン1またはバージョン2のAppStoreサーバー通知を選択できるようになります。
これらの変更が今年後半に開始されると、バージョン2のAppStoreサーバー通知にオプトインできるようになります。
だから今、私はいくつかのシナリオ例を見てみたいサブスクリプションの初回購入から開始して、新しいAppStoreサーバー通知を使用します。
アプリでの初めてのサブスクリプション購入の場合、購入の結果として署名されたトランザクション情報を受け取ります。
アプリでこれを確認してoriginalTransactionIdやその他の関連フィールドをサーバーに送信するか、署名済みのトランザクション情報をサーバーに送信して確認し、その時点でデータベースに保存するフィールドを選択するかを選択できます。
ほぼ同時に、サブステートがINITIAL_BUYのSUBSCRIBED通知を受け取ります。通知の署名済みトランザクション情報にアプリアカウントトークンが含まれるようになったので、購入後にサーバーとアプリの間の通信が失われた場合でも、この通知をアプリ内ユーザーにすぐにリンクできます。署名されたトランザクション情報を確認するためにサーバーを呼び出す必要はありません。
originalTransactionIdを送信して、ステータスまたはアプリ内購入履歴APIを確認したい場合は、いつでもサーバーを呼び出すことができます。
これで、サブスクリプションの購入について説明しました。
サブスクリプションの更新に移りましょう。
これで、このサブスクリプションの更新に到達しました。
このサブスクリプションが正常に更新されると、通知タイプDID_RENEWが送信されます。
あなたは署名された取引情報を見ることができますペイロード内の署名された更新情報は、サブスクリプションの次の更新日と、次の更新に対する顧客の更新設定を確認します。
フェイルオーバーメカニズムとして、サブスクリプションステータスAPIを呼び出して、更新時にサブスクリプションのステータスを確認するジョブをスケジュールすることもできます。
繰り返しになりますが、通知で受け取った取引を確認するために電話をかける必要はありません。
もちろん、自動更新は、特に請求の問題がある場合は、必ずしも計画どおりに進むとは限りません。
だから今、私は猶予期間と請求の再試行をカバーしたいと思います。ここで、サブスクリプションが期待どおりに更新されなかったとしましょう。
これが発生すると、DID_FAIL_TO_RENEW通知で通知されます。猶予期間が有効になっていて、サブスクリプションが正常に更新されずに猶予期間を終了した場合、GRACE_PERIOD_EXPIRED通知が送信され、顧客が請求の再試行期間に入ったことを確認できます。
請求の再試行期間中にサブスクリプションがまだ回復されない場合は、BILLING_RETRYのサブステージを含むEXPIRED通知が送信されます。
猶予期間中または請求の再試行期間中にサブスクリプションの請求を回復すると、DID_RECOVER通知が送信されます。
更新の結果に関係なく、署名されたトランザクション情報と署名された更新情報を含むv2通知で結果を通知します。
このプロセスの任意の時点でサブスクリプションステータスまたは履歴APIを呼び出して、サブスクリプションステータスを再確認できます。
現在、お客様がアプリで購入するのはサブスクリプションだけではないことがわかりました。
それでは、消耗品を初めて購入するときに何を期待するかをピボットして説明しましょう。
アプリで消耗品を初めて購入する場合は、購入の結果として署名された取引情報を受け取ります。
アプリでこれを確認し、originalTransactionIdおよびその他の関連フィールドをサーバーに送信することを選択できます。
または、署名されたトランザクション情報をサーバーに送信して確認し、その時点でデータベースに保存するフィールドを選択します。
後で必要になる可能性があるため、originalTransactionIdを常にメモしておいてください。
消耗品や、非消耗品や非更新サブスクリプションなどの他のコンテンツタイプの場合、顧客が払い戻しを要求しない限り、その購入のライフサイクル全体で大きな変化はありません。
だから私は今そのケースをカバーしたいと思います。
ここで、顧客が消耗品の購入の払い戻しを要求するとします。
署名された取引情報に失効日と失効理由が記載された払い戻し通知をお送りします。
失効日以降、消耗品の購入へのアクセスの提供を停止することを知ることができます。
消耗品の購入状況がいつでも気になる場合は、アプリ内履歴APIを呼び出して、応答でそれを探すことができます。
キャンセルされた消耗品は常に含まれるため、取引状況が変更されたかどうかがわかります。
次に、停止について説明します。
最善の努力にもかかわらず、サーバーが停止する場合があります。
次に、サーバーが停止から回復するのを支援する方法について説明します。
サーバーで停止が発生し、App Storeサーバーの通知を見逃した場合は、その間に何が変わったかを知りたいと思うでしょう。
アプリ内履歴APIは、ここでのソリューションです。
各顧客のAPIを呼び出して、アプリからoriginalTransactionIdを指定するだけで、アプリのトランザクションの最新の履歴を取得できるため、サーバーを更新できます。
次に、サブスクリプションステータスAPIを呼び出して、各サブスクリプションの最新のサブスクリプションステータスを取得できます。
ここで、最後の1つのケース、つまりサーバー上の署名付きトランザクションへの移行について説明します。
これは、アプリの前にサーバーを更新する準備ができている場合、または統合アプリの領収書をまだ受け取っている場合に特に重要です。
アプリの古いバージョンから。
必要なのはoriginalTransactionIdのみであるため、サーバー上の署名付きトランザクションへの移行は簡単です。
サーバーがアプリから受信する統合アプリレシートをJWSレシートに簡単に変換できるため、サーバーはAppStoreサーバーAPIおよびAppStoreサーバー通知と互換性があります。
これを行うには、最初に統合アプリレシートを使用してverifyReceiptを呼び出し、応答からすべての一意のoriginalTransactionIdをプルします。
これらのoriginalTransactionIdのいずれかに対してアプリ内購入履歴APIを呼び出して、署名されたトランザクションでのアプリの履歴を取得します。
次に、サブスクリプションステータスAPIを呼び出しますサブスクリプションoriginalTransactionIdを使用して、すべての顧客サブスクリプションの署名済みトランザクションとsignedRenewalInformationを取得します。
署名されたトランザクションのペイロードから関連データを書き留めると、これらのAPIを引き続き使用し、v2 AppStoreサーバーの通知を受信する準備が整います。
これで、App Storeサーバー通知に加えられたすべての変更と、通知を使用して顧客のステータスを確認する方法について説明しました。
次に、サーバーからのアプリ内購入の家族共有を管理しやすくする方法について説明します。
App Store Connectでアプリ内購入のファミリー共有を有効にしている場合、アプリ内購入のファミリー共有は現在、自動更新可能なサブスクリプションと非消耗品購入でサポートされています。
現在、トランザクションが家族で共有されているか購入されているかを示すinAppOwnershipTypeというフィールドを提供し、家族の通知のサブセットであるREVOKE、DID_RECOVER、およびDID_FAIL_TO_RENEWをサポートしています。アプリ内所有権タイプフィールドと既存のサポートされている通知タイプ署名された新しいトランザクションとAppStoreサーバー通知v2はそのまま残ります。
ただし、今年後半には、家族向けのAppStoreサーバー通知のサポートが追加されます。
v1通知の場合、DID_CHANGE_RENEWAL_STATUS、DID_CHANGE_RENEWAL_PREF、DID_RENEW、およびINTERACTIVE_RENEWALを追加します。
v2通知については、家族のサポートをさらに追加しています。DID_CHANGE_RENEWAL_STATUS、DID_CHANGE_RENEWAL_PREF、およびDID_RENEWに加えて、購入者と家族のSUBSCRIBED、EXPIRED、GRACE_PERIOD_EXPIRED、およびOFFER_REDEEMEDのサポートが追加されています。
これにより、App Storeサーバーの通知を通じて、購入者と家族の両方のすべての顧客のステータスを追跡することがさらに簡単になります。
そのため、今年は家族向けの通知の変更が予定されており、既存の家族共有機能と組み合わせると、アプリ内購入の家族共有の管理がさらに簡単になります。
ここで、もう1つ、サンドボックスでサーバーをテストすることで締めくくりたいと思います。
アプリとサーバーに自信を持っていただきたいと思います。
そのため、サンドボックスで新しいApp Store ServerAPIおよびAppStoreサーバー通知と統合できるようにしてください。
生産前。
本日説明したAppStore Server APIの場合、サンドボックスで完全にテスト可能であり、今からライブになります。
これには、サブスクリプションステータスAPIとアプリ内購入履歴APIが含まれます。
これに加えて、サンドボックスに他のいくつかの新機能を追加しています。
今年後半に、App StoreConnectでサンドボックス固有の通知URLを追加できるようになります。
この追加により、本番通知とサンドボックス通知を完全に分離しておくことができます。
さらに、サンドボックス通知のバージョンを選択して、本番環境の前にサンドボックスでv2通知をテストすることもできます。
昨年、トライアルの資格をリセットしたり、サンドボックスに[サブスクリプションの管理]ページを提供したりするなど、サンドボックスのエキサイティングな改善をいくつかもたらしました。
サンドボックスでのテストをより簡単にし続けたいと考えており、今年はいくつかの新しい拡張機能を追加しています。
これらは、サンドボックスApple IDの購入履歴のクリア、サンドボックスアカウントリージョンの変更、およびサンドボックスでのサブスクリプション更新率の調整です。
さらに、セキュリティ強化として、お客様がTestFlightユーザーではなくなったことを検出すると、TestFlightレシートのverifyReceiptからエラーが返されます。
これらの新しいサンドボックスの機能強化は、App StoreConnectのサンドボックステスターページからアクセスできます。
購入履歴をクリアするには、[編集]を選択し、テスターを切り替えて、[購入履歴のクリア]ボタンを選択します。
テスターの購入履歴のクリアを確認すると、アクションを元に戻すことはできません。
したがって、このオプションを選択したテスターを覚えておいてください。
購入履歴のクリアは、新しいアカウントを作成せずに何かを再度購入できる強力な新しいテストツールです。
また、テスト用に新しい空の領収書を用意することもできます。
アカウントリージョンを変更したり、サブスクリプションの更新率を調整したりするには、テスターページに戻り、テスターの行を選択します。
テスターの設定には、App Storeの地域を変更したり、サブスクリプションの更新率を調整したりするための新しいオプションが表示されます。
目的のリージョンを選択することで、テスターのアカウントリージョンを変更できます。
これにより、サンドボックス内の175のストアフロントで、すべて1つのテスターアカウントでテストすることが可能になります。
最後の新しいサンドボックス機能は、サンドボックスでのサブスクリプション更新率を調整することです。
これを編集するには、ドロップダウンから希望の更新率を選択します。
現在、1か月はサンドボックスで5分に相当します。
テスターの更新率を調整するためのオプションをさらにいくつか提供します。
サブスクリプションの更新率を調整すると、サブスクリプションのキャンセル、アップグレード、ダウングレードなどを行うための時間が長くなり、更新を迅速に高速化できます。
長期的な顧客をシミュレートします。
今年サンドボックスに来るのはこれだけです。
これらの新機能を使ったテストを気に入っていただければ幸いです。
それで、今日はたくさんの新しい情報をカバーしました。
そして今、私はあなたにそれらすべてを探求することができるようにして欲しいです。
新しいJWSレシートを採用するために、アプリとサーバーを更新するために少し時間がかかることを願っています。
新しいAppStore Server APIを、特に現在稼働しているサンドボックスで利用してください。
また、App Storeサーバーの通知をまだ登録していない場合は登録し、今年後半にリリースされるv2アップデートの準備をしてください。
新しいサンドボックスの機能強化も今年後半に予定されています。
これらを利用して、サンドボックステストのエクスペリエンスを向上させます。
最後に、このシリーズの他の2つのセッション、「Meet StoreKit 2」と「顧客をサポートし、払い戻しを処理する」を確認してください。
よりApp Storeのサーバー通知の背景については、どのようにあなたは、それらを設定することができ、「アプリ内購入に新機能」チェックアウト
WWDC 2020からと、「アプリ内の購入とサーバー間の通知を使用して」
WWDC 2019年から当社レシート、API、通知は、サーバーからのアプリ内購入を管理するために必要な3つの強力なツールです。
これらを利用することで、サーバーとアプリをこれまで以上に強力にすることができます。
私たちのすべての新機能を活用してください皆様からのフィードバックをお待ちしております。
本日はお聴きいただき、誠にありがとうございました。残りのWWDCをお楽しみください。
【明るい音楽】
コメント