サーバにおけるApp内課金の管理

こんにちは WWDCへようこそ Toriです　サーバに 導入される新機能と App内課金の状況を 把握するための 効果的なサーバ運用の ガイドラインについて お話しすることができて 大変うれしく思います では 始めましょう このセッションは App内課金に関する ３回のシリーズのパート２です "StoreKit 2について"や "顧客サポートと返金処理"を まだご覧になってない場合は 後ほどご覧いただき 全体像を把握いただくことを おすすめします このセッションでは サーバに 焦点を当て App内課金を管理する サーバの 構築について説明します セッションを始めるにあたり まずは サーバがある メリットについて説明します サーバのメリットは いくつかありますが App内課金の場合 そのほとんどは 状況を 把握できることにあります サーバをお持ちの場合 App Storeのサーバ通知で App内課金の 状況が変化した際に リアルタイムで通知ができ サーバ間のAPIを使って オンデマンドで呼び出し 状況の確認が可能です サーバがあると 顧客のデバイスが オフラインであったり App外でステータスが 変化しても 顧客の コンテンツへのアクセスを 検証できます そのため リニューアル後も 顧客のサブスクリプションが 継続しているのか ゲーム内で購入したコインが 返金されたのか把握できます すでにサーバを お持ちの方は これらの 理由で設置されて いるかもしれません サーバをお持ちでなく 構築を検討中の方には コンテンツへの コントロールが増すことは 検討に際しての 大きな理由となるでしょう サーバをお持ちであっても iPhone iPadや その他の端末における App内課金から ストーリーは開始されます。 transactionIdや originalTransactionId レシートなどの 購入情報を サーバに送信すると 当社のサーバと直接 通信することで その購入を追跡 できるようになります 現在は verifyReceiptのようなAPIや App Storeサーバ通知などの フレームワークを使用し 当社サーバとの連携を 強化することができます そこで 本日のコンテンツです 今回は サーバ側で 予定されている すべての変更点をおさらいし これらを統合して より良い 強力な サーバを構築する 方法をご紹介します まずは App Storeレシートでの アクセスの検証についてと App StoreサーバAPIでの ステータスの追跡方法 次に App Store サーバ通知による ステータスのパッシブな 追跡方法について ご説明します またファミリー共有の 管理についてと サンドボックス内での サーバの テスト方法についても 説明します

では レシートを使って ステータスを 検証してみましょう レシートのフォーマットは 現在 統一されています レシートのJSONバージョンを 取得するには　Appで デバイス上の レシートを検証するか サーバ間verifyReceipt エンドポイントを 呼び出す必要があります サーバ間で呼び出すと このデコードされた レシートの他にも 最新の トランザクションと 今後の更新情報を pending_renewal_info セクションと latest_receiptで 取得できます このレシートは かなりの量になり 非消耗型や消耗型 サブスクリプションや 非自動更新サブスクリプション 情報を含みます かなりの 情報量になるため 多すぎると 感じるかもしれません さらに StoreKit 2では 新たにクライアント側に JWS（JSON Web Signature） 形式の署名付き トランザクションを 導入しており サーバ側でも同様に 提供したいと 考えています 署名付きトランザクションの 導入の理由ですが セキュリティは Appleにとり重要なものです トランザクションへの署名に JWSを 使用することで 署名を検証でき セキュリティが向上します さらに トランザクションは デコードと検証が容易なため 当社サーバを呼び出さずに お客様のサーバで 実行可能です 署名済みトランザクションを 見てみましょう 署名済みトランザクションは ピリオドで区切られた ３つの文字列で構成されます 最初の文字列はbase64 エンコードのJSONヘッダー 次にbase64エンコードの JSONペイロード その後に署名が続きます ヘッダーをbase64で デコードすると 使用された 署名アルゴリズムと x5Cクレームが含まれています これは署名の検証に必要な 証明書チェーンを含みます 署名の検証については 後ほどお話しします 次に ペイロードを base64でデコードすると レシートJSONが 表示されます トランザクションの デコードに必要なのは ペイロードをbase64で デコードすることだけです これはお客様の サーバ上で独自に 実行できる 簡単な操作です ではトランザクションを 見てみましょう 一目見るだけでも 複数のデータタイプが 以前のレシートの 文字列から より適切な 数値やブーリアンなどに 変更されています また 日付形式が エポックからの経過時間 （ミリ秒）の１つだけに 削減されています 複数の新しいフィールドも 追加されています トランザクションを適用する コンテンツタイプを示す というフィールドを 追加しました という フィールドも追加しました StoreKit 2 Appでの 購入時に この値をStoreKitに渡すと サーバに保持され 各トランザクションで 返されます これは新規の署名付き トランザクションだけでなく 既存の統合App レシートでも トランザクションごとに 返します 次にご紹介する ２つのフィールドは 新しいものではなく 名称が変更されたものです cancellation_dateと cancellation_reasonを revocation_dateと revocation_reasonに 名称変更したことで これらのフィールドが 存在すると 失効日の時点でサービスを 取り消す必要があると 明確になります 最後の２つのフィールドは 一見新しいですが 実際には 以前のレシートにあった いくつかの情報を 単純化したものです isTrialPeriodと isIntroOfferPeriod promotionalOfferIdentifier およびofferCodeRefNameが offerTypeと offerIdentifierになります offerTypeは顧客がこの期間に 適用したオファーの種類を 示し １はイントロオファー ２はサブスクリプションオファー ３はオファーコードです オファータイプが２や ３の場合は オファー識別子フィールドに プロモーションオファーID またはofferCodeRefNameの いずれかの値が表示されます では 署名付き トランザクション情報の 署名部分の検証について お話しします 署名の検証では そのトランザクションが Appleからの信頼できる ものであることを検証します トランザクションの 内容のみを確認する場合は この手順は必要ありません 署名を検証するには 署名付き トランザクション情報の ヘッダー部分の クレームを利用する 必要があります 使用した署名アルゴリズムを 知るためにはalgクレームを 使用し x5cクレームの配列の 証明書チェーンを使用します

この２つを入手したら お好みの暗号ライブラリを 使って 署名済み トランザクション情報の 署名を 検証することができます 以上が App Storeレシート すなわち 署名済みトランザクションの 変更点になります

次にAPIを使ってステータスを 確認する方法をご紹介します 署名済みトランザクションの 有効性を確認したり トランザクションを デコードするために このverityReceiptのような APIは必要ありませんが お客様のサーバで 役立つAPIを構築したいと 考えていました そこで今年のWWDCでは App StoreサーバAPIの まったく新しいライブラリを ご紹介します このライブラリでは これまでサーバ上で 利用できなかった新機能が 複数提供され 署名済みトランザクションも 新たに利用できます では２つの新しいAPI サブスクリプション ステータスAPIと App内課金履歴APIを 今から解説します まずサブスクリプション ステータスAPIです サブスクリプション ステータスAPIは originalTransactionIdで 表示される 自動更新 サブスクリプションの 最新ステータスを 提供します このAPIによって 利用者の ステータスをすばやく 確認できます ユーザーの サブスクリプションが 有効か 期限切れなのか 猶予期間中なのか その他の状態なのかを 簡単にチェックできます では見てみましょう このAPIへの リクエストは簡単で originalTransactionIdと URLが必要です このAPIからの応答は 顧客がAppで利用している すべての サブスクリプションの ステータスを含み subscriptionGroupIdentifier でグループ化されます subscriptionGroupIdentifier ごとに 最新トランザクションの リストを提供し グループの 各originalTransactionIdの エントリを用意しています この配列の各エントリには ステータス originalTransactionId signedTransactionInfo signedRenewalInfoが 含まれ JWS形式で 署名されています ステータスフィールドについて 詳しく見てみましょう

ステータスフィールドには サブスクリプションの ステータスが 表示されるため 利用者にサービスを 提供すべきかどうかを 判断できます ステータスには ５つの値があります サブスクリプションの 有効を示す１ サブスクリプションの 期限切れを示す２ サブスクリプションの 課金を再試行中の３ サブスクリプションが 猶予期間中の４ サブスクリプションの 解約や その他の理由で 無効になったことを 示す５があります ステータスフィールドを見ることで サブスクリプションの 状況をすぐ把握できます ステータスの詳細については 署名済みトランザクション 情報のペイロードと 署名済み更新情報の ペイロードで確認できます signedRenewalInfoを デコードするには 署名済みトランザクション 情報の場合と同様に ペイロード部分を base64でデコードします

signedRenewalInfoの 署名を認証する際にも同様に ヘッダーを使用します デコードすると このように表示されます 更新情報には verifyReceiptの 保留中の更新情報 セクションと同様の フィールドが含まれており 日付のフォーマットや ブーリアンの使用などの 更新が施されています また新たにofferTypeと offerIdentifierが signedRenewalInfoに 追加される予定です これにより 顧客が次回の 更新時にオファーを 利用する予定があるかを 把握できます サブスクリプション ステータスAPIに加えて verifyReceiptの latest_receipt_infoで 提供しているような Appに関連する すべてのトランザクションを 取得する方法も 提供したいと考えています そのために App内課金履歴APIも 追加しています App内課金履歴APIは verifyReceiptの latest_receipt_infoと 同じように Appのトランザクションの 全履歴を提供します ここでの主な違いは 各トランザクションが 新しい署名済み トランザクション情報形式で 行われることと APIがページングされ App Storeから受け取る 応答のサイズを 制御できることです この初期リクエストは サブスクリプション ステータスAPIと同様 非常にシンプルです リクエストの処理に 必要なのは originalTransactionId のみです するとApple IDや バンドルIDなどの Appのメタデータと Appの最新20件の トランザクション一覧が 新しい署名付き トランザクション情報形式で 返って来ます リクエストごとに20件の 署名付き情報が返って来ます トランザクションが さらにある場合は 応答の hasMoreとリビジョン値を ご確認ください まだ他のトランザクションが 残っている場合 hasMoreはtrueになります 次の20件の情報を 取得する場合 リビジョントークンを クエリパラメータとして 別のリクエストを行います hasMoreがfalseに なるまで繰り返します ここで話は変わり App Storeサーバの すべてのAPIが どうやって相互に整合性を 取るかについてお話しします これらはすべてJWT （JSONウェブトークン）の 認証を受け 新しい署名付き トランザクションを サポートし JSONの要求と 応答形式を備えています これらはすべて リクエストで送信した originalTransactionIdを キーとしており レシートや共有秘密鍵を 必要としません ここで JWT認証に ついてご説明します 新しいApp Store サーバAPIはすべて JSON Web Token（JWT） 認証を利用します 当社のサーバと 皆様のサーバ間の 通信のセキュリティを 強化するための選択です このJWTを生成するには App Store Connectから 秘密鍵をダウンロードする 必要があります このプロセスにより 公開鍵がサーバに 自動的に登録されます 次にサーバを呼び出す前に ES256アルゴリズムを使用して トークンに 署名する必要があります App Store Connectで 秘密鍵を 生成するには ページで タブにアクセスします App内課金 キーオプションを選択すると 次のような ページが表示されます キーを追加して 名称を付けます ダウンロードは １回のみ可能なので キーを安全な場所に保管し キーIDをメモしておきます ではJWTを実際に 見てみましょう JWTはヘッダー　ペイロード 署名の３つの部分で 構成されます ヘッダーには 秘密鍵の鍵IDと 署名に使用する アルゴリズムを 含める必要があります SHA 256ハッシュ（ES256）を 使用した 楕円曲線署名が必要です トークンタイプも （この場合は常にJWT） 含める必要があります ペイロードには 発行者IDも必要です これはApp Store Connectで ご覧いただけます トークンの発行時刻と 有効期限をエポック からの秒数で含めます この２つの時間の差は １時間以内と なっています オーディエンスは常に appstoreconnect-v1です

１度だけ使用する文字列 ナンスを生成します 最後に Appの バンドル識別子を 含めます 情報がすべてそろったら ES256アルゴリズムを 使用して このトークンの署名を 実装するか SHA256ハッシュで 楕円曲線署名を行います 次に進む前に App StoreサーバAPIの 重要ポイントを おさらいします まず ステータスの判定と トランザクション履歴を 調べることは 別の機能ですので 分けて扱いました 次に これらのAPIでは originalTransactionIdのみが リクエストに必要です つまり Appから あるいはサーバからの 応答で受け取った 署名付きトランザクションの originalTransactionIdなど 必要なフィールドのみを 使用して 署名付き トランザクション情報を 処分することができます 過去にレシートで ご案内していたような 署名付きトランザクションの 保存は不要です 新しいApp Store サーバAPIを使って 顧客のステータスを 確認する方法は以上です ではApp Store サーバ通知が どのように統一されたかと 通知によるステータスの 確認方法をご説明します まず App Storeサーバ通知を 簡単におさらいしましょう App Storeサーバ通知 については 以前から取り上げてきました その利便性をご紹介します App Storeサーバ通知では トランザクションの ステータスが 変化した時に App Storeから直接 通知を 受け取ることができます 通知を受け取ると お客様が スマートフォンで Appを開かずとも 直ちにステータスの 更新が可能となります App Storeサーバ通知では 当社サーバへの アクセスも不要です 何か変化があれば 通知を発信します これは お客様側の サーバで 利用可能な 最も強力なツールの１つです 当社の今年の目標は 新しく使いやすくなった 署名付きトランザクションを 活用して App Storeサーバ通知を さらに強化することです これに加えて １つのユーザーアクションに １つの通知のみが 送られるよう改善し ペイロード全体を JWSを使って 署名することで セキュリティを 強化するための アップデートにも 取り組んで行きたいと 思っています また 準備ができ次第 v2通知への オプトインができるようにし 当面は 既存の通知も 送信し続ける予定です こちらが現在提供している v1通知となります INITIAL_BUYから REVOKEまで 11種類あります v2通知では INITIAL_BUY INTERACTIVE_RENEWAL CANCEL PRICE_INCREASE_CONSENTの ４種類の通知タイプを 廃止します 追加の通知はSUBSCRIBED OFFER_REDEEMED EXPIRED GRACE_PERIOD_EXPIRED PRICE_INCREASEです 新たな通知タイプに加えて “サブステート”と呼ばれる フィールドを新規追加します これにより 一般的な 通知タイプを特定の ユーザーアクションに 絞り込むことができます 現在サブステートが 適用される v2通知は以下の ６種類となります SUBSCRIBED DID_CHANGE_RENEWAL_STATUS DID_CHANGE_RENEWAL_PREFERENCES OFFER_REDEEMED EXPIRED PRICE_INCREASE これらの通知タイプに サブステートが どのように適用されるかの 例を見てみましょう まず SUBSCRIBED 通知と そのサブステートの 説明をします 顧客の初回購入時は SUBSCRIBED 通知に INITIAL_BUYの サブステートが付きます 顧客が同じSKUを 再購入したり 異なるSKUを 購入した場合でも 同じサブスクリプションの グループ内であれば SUBSCRIBED 通知に RESUBSCRIBEの サブステートが付きます v1 App Storeの サーバ通知に 同等の 通知タイプが 無いものの１つに OFFER_REDEEMED 通知があります こちらの例をご覧ください OFFER_REDEEMEDは 顧客が プロモーションオファーを 利用すると通知されます 顧客が初回購入時に オファーを利用した場合 OFFER_REDEEMEDの通知に INITIAL_BUYが付きます 顧客が非アクティブな サブスクリプションの 再購入にオファーを 利用した場合 OFFER_REDEEMEDの通知に RESUBSCRIBEが付きます 顧客が有効な サブスクリプションを アップグレードする際に オファーを利用した場合 OFFER_REDEEMEDの通知に UPGRADEが付きます 顧客が有効な サブスクリプションの ダウングレードに オファーを利用すると OFFER_REDEEMEDの通知に DOWNGRADEが付きます さらに 顧客が同じ 期間内に解約した後に オファーを利用して サブスクリプションを 再購入した場合は OFFER_REDEEMEDの通知に AUTO_RENEW_ENABLEDが 付きます 次にEXPIREDを見てみましょう 新しい通知タイプの EXPIREDでは 顧客が自動更新を 無効にした後に サブスクリプションの 期限が切れると VOLUNTARYの サブステートが付きます 請求の再試行期間内に 課金が出来ずに サブスクリプションが 終了した場合は EXPIREDの通知に BILLING_RETRYが付きます さらに 顧客が 値上げに同意せずに サブスクリプションが 失効すると EXPIREDの通知に PRICE_INCREASEが付きます このようにv2通知と サブステートを 組み合わせることで 20以上の異なる 顧客の ライフサイクルイベントを カバーできます 通知タイプを見るだけでも 購入の変更点を 大まかに 把握することができますが サブステートを見ることで より具体的な状態について 詳細に把握できます 新しいペイロードを 簡単に見てみましょう v2通知の場合も 通知の種類に 関係なく 常に同じ フィールドの セットが含まれます 通知タイプ　サブタイプ 通知バージョンは v2通知を利用する際は ２になります 通知が適用される環境 バンドルIDなどの Appのメタデータ AppのApple ID バンドルバージョン 影響を受けるApp内の 最新のトランザクションは 新たな署名付き トランザクション情報 形式です　そして新しい signedRenewalInfo形式による 対象となるApp内の 最新の更新情報です これらの変更によって 通知の解析が容易になり 新しい署名付き トランザクションでは 影響を受けるApp内 課金に関する 情報のみが含まれるため 多くの方に ご採用いただけると思います 先ほどお話ししたとおり 通知の安全性と 信頼性を高めるために ペイロード全体が 署名されます 先ほどのペイロードは 読みやすくするため 署名されていませんが 署名はJWS形式の トランザクションや 更新情報への署名と同様です 準備が整い次第 v2通知への オプトインをお願いします このために App Store Connectの 通知URLに オプションを追加し App Storeサーバの 通知バージョンの 選択が可能になっています これを行うには Appのページに移動し 新しいApp Store サーバ通知セクションを ご覧ください 本番サーバの URLを選択すると App Storeサーバ通知の バージョン１または２から 選択できます これらの変更が 今年後半に適用されると App Storeサーバ通知の バージョン２にオプトイン できるようになります では新しいApp Store サーバ通知を 使った場合の事例を サブスクリプションの 初回購入の場合から 説明したいと思います サブスクリプションを始めて Appで購入した場合 購入の結果として署名入りの トランザクション 情報が届きます これをAppで検証し originalTransactionIdと その他の関連フィールドを お客様のサーバに 送信するか 署名付きトランザクション 情報を お客様のサーバに送信して 検証し データベースに 保存するフィールドを 選択することもできます ほぼ同時に サブステートが INITIAL_BUYの SUBSCRIBED 通知が届きます 通知に含まれる署名付き トランザクション情報に Appのアカウント トークンが含まれるため 購入後にサーバと Appの間で 通信が途絶えたとしても この通知をAppの ユーザーと 紐づけることが可能です 署名付きトランザクション 情報を 確認するためにサーバを 呼び出す必要はありません 当社に originalTransactionIdを 送信して ステータスや App内課金履歴APIを いつでも確認できます 以上がサブスクリプションの 購入です サブスクリプションの 更新に移ります サブスクリプションの 更新時期となり サブスクリプションが 正常に更新されると DID_RENEWの 通知が送信されます ペイロード内の 署名付きトランザクション 情報と更新情報を見ることで 顧客のサブスクリプションの 次回更新日と 次回の更新設定を 確認できます また フェイルオーバーとして 更新時にサブスクリプション ステータスを 確認するために サブスクリプション ステータスAPIを呼び出す ジョブを事前設定できます こちらも 通知を受け取った トランザクションを 検証するためにサーバを 呼び出す必要はありません もちろん 自動更新が計画 通りに行かないこともあり 課金の問題がある場合は 注意が必要です そこで猶予期間と請求 再試行のお話しになります サブスクリプションが 期待に反して 更新されなかったとします この場合は DID_FAIL_TO_RENEWが 通知されます 猶予期間が有効となっており サブスクリプションが 更新されずに 猶予期間が終了した場合 GRACE_PERIOD_EXPIREDが 通知され 顧客が課金再試行期間に 入ったことが分かります 課金の再試行期間中に サブスクリプションが 再開しなかった場合は EXPIRED 通知に BILLING_RETRYの サブステートが付きます 猶予期間または 課金再試行中に サブスクリプションの 課金が回復すると DID_RECOVER 通知が送信されます 更新の結果に関わらず 署名付き トランザクション情報と 更新情報を含む v2通知を送信します このプロセスの お好きな時点で サブスクリプションの ステータスや 履歴APIを呼び出して 状態を再確認できます 顧客がAppで購入するのは サブスクリプションだけとは 限りません そこで話題を変えて 消耗型を始めて 購入する際の注意点を お話しします Appで初めて 消耗型が購入されると 署名付きトランザクション 情報を 購入の結果として 受け取ります App上で検証し originalTransactionIdや その他の関連フィールドを お客様のサーバに 送信するか 署名付きトランザクション 情報をお客様の サーバに送信して検証し データベースに保存する フィールドを選択できます 後で必要になる時のために originalTransactionIdは 常に保管して おいていください 消耗型や非消耗型 非自動更新 サブスクリプションのような コンテンツの 種類の違いは 顧客が 返金を請求しない限り ライフサイクル全体で 大きくありません 返金については これからご説明します 顧客が購入した消耗型の 払い戻しを請求するとします 署名付きトランザクション 情報に 失効日と失効理由を記載した REFUND通知が送信されます 失効日以降 消耗型へのアクセスの 提供を停止します 消耗型の購入状況が 気になる場合は App内の 履歴APIを呼び出し 内容を確認できます キャンセルされた 消耗型も含まれるので トランザクションの 変化を確認できます 次に 障害発生時の 説明をします 最善の努力にもかかわらず サーバに 障害が発生する 場合があります そこで 障害発生時の サーバの 復旧方法について お話しします サーバに障害が発生し App Storeサーバ通知が 届かない場合 その間の 状況を確認したいでしょう その場合もApp内の 履歴APIを使用します 顧客ごとにAPIを呼び出し originalTransactionIdを Appから提供するだけで 最新の トランザクション履歴を 取得し サーバを更新できます 次にサブスクリプション ステータスAPIを 呼び出して 各サブスクリプションの 最新の状態を 取得できます 次に最後のケースとして サーバ上での 署名付きトランザクションへ の移行についてご説明します これはAppより先に サーバを更新する 準備が出来ている場合や 古いバージョンのAppで 統合レシートを 使用している場合に重要です サーバ上での署名付き トランザクションへの移行は originalTransactionIdが あれば簡単です サーバがAppから 受信する 統合Appレシートは JWSレシートに 簡単に変換でき App StoreサーバAPIや App Storeサーバ通知に 対応できます これにはまず 統合Appレシートで verifyReceiptを呼び出し 一意の originalTransactionIdを すべて引き出します originalTransactionId に対応したApp内購入 履歴APIを呼び出し Appの署名付き トランザクションの 履歴を取得します 次に サブスクリプションの originalTransactionId を呼び出して すべての顧客の サブスクリプションの signedRenewalInformation を取得します 署名付き トランザクションの ペイロードから関連する データを書き留めれば APIを継続して使用し v2 App Storeサーバ通知を 受信できるようになります 以上がApp Storeサーバ通知で 予定されている 変更点と 通知を使って顧客状況を 確認する方法となります

ではApp内課金の ファミリー共有を サーバから簡単に管理する 方法についてご説明します App内課金のファミリー共有は App Store Connectで ファミリー共有を有効に している場合 現在 自動更新型の サブスクリプションと 非消耗型の購入で サポートされています 現在トランザクションが 家族で共有されているか 購入されているかを示す inAppOwnershipTypeという フィールドを提供しており 通知のサブセットとして REVOKE　DID_RECOVER DID_FAIL_TO_RENEWを サポートしています App内の所有権タイプの フィールドと 現在サポートされている 通知タイプは 新しい署名付き トランザクションと App Storeサーバ通知 v2にも残されます しかし今年後半には 家族向けの App Storeサーバ通知の 機能を強化する予定です 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 サーバ通知を 利用して 購入者と家族 両方の状況を 把握することが さらに容易になります 今年 家族向けの通知機能が 変更されることにより 従来の ファミリー共有機能と合わせて App内課金の ファミリー共有の管理が さらに簡単になります そして最後のトピックですが サンドボックスでの サーバのテストにより Appとサーバを確実に 運用いただきたいと思います そこで本番環境の前に サンドボックスで新しい App StoreサーバAPIと App Storeサーバ通知を ご利用いただけます 本日説明した App StoreサーバAPI の場合はサンドボックスで 完全なテストが可能であり すでに稼働しています これにはサブスクリプション ステータスAPIと App内課金履歴APIも 含まれます これに加えて サンドボックスに複数 新機能も追加しています 今年後半に App Store Connectで サンドボックス固有の 通知URLを追加可能です この追加機能により 本番環境と サンドボックスの通知を 完全に分離できます さらに サンドボックスでの 通知のバージョンが 選択可能になるので 本番前にサンドボックスで v2通知をテストできます 昨年はトライアル資格を リセットしたり サンドボックス内での サブスクリプションの 管理ページの提供などの 改善点をお届けしてきました サンドボックスでの テストをより簡単にするため 今年も複数の新しい 拡張機能を追加しています サンドボックスでの Apple IDの購入履歴消去 アカウントリージョンの変更 サブスクリプション更新率の 調整機能などです また セキュリティの 強化として 顧客がTestFlightユーザーで ないと検出されると TestFlightレシートの verifyReceiptから エラーが返されます これらのサンドボックスの 新たな機能強化は App Store Connectのテスター ページでアクセスできます 購入履歴を消去するには 編集を選択し テスターを切り替えて 購入履歴の消去 ボタンを選択します テスターの購入履歴が 消去されると アクションを 元に戻すことはできません どのテスターを選択したかを 覚えておいてください 購入履歴を消去することで 新しいアカウントを 作成せずに 再度購入を行える 新しい 強力な テストツールとなります テスト用に新しい 空のレシートを 用意することもできます アカウントのリージョンを 変更したり サブスクリプションの 更新率を調整するには テスターページから テスターの行を選択します

テスターの設定には App Storeの リージョンの変更や サブスクリプションの更新率 調整用オプションがあります

ご希望のリージョンを 選択すると テスターのアカウント リージョンを変更できます １つのテスターアカウントで 175のストアフロントを テストすることが 可能になります 最後にご紹介するのは サブスクリプション更新率の 調整機能です これを調整するには ドロップボタンから 希望の更新率を選択します サンドボックスの５分が １カ月に相当しています テスターの更新率 調整については さらにオプションを 提供予定です サブスクリプションの 更新率を調整することで キャンセル　アップグレード ダウングレードなどを 試す時間を 増やすことができます また 長期顧客を シミュレートするために 更新の高速化も可能です こちらがサンドボックスの 今年の更新予定となります 新規テスト機能を気に入って いただければ幸いです 本日は多くの情報を お伝えしましたが ぜひ色々とお試しください Appやサーバを アップデートいただいて 新しいJWSレシートを ぜひご利用ください 今すぐご利用いただける サンドボックスなど 新しいApp Storeサーバ APIもご活用ください まだ登録がお済みでなければ 年内に予定されている v2通知へぜひご登録ください サンドボックスの機能強化も 今年後半に予定されています ぜひ新しいサンドボックスを ご活用ください 最後に このシリーズの 他の２つのセッション “StoreKit 2について”と “顧客サポートと返金処理”も ご覧ください App Storeサーバ 通知の仕組みや 設定方法については WWDC 2020の “App内課金に関する 新機能”と WWDC 2019の “App内課金と サーバ間通知の使用"を ご覧ください 当社のレシートやAPI 通知は App内課金をサーバから 管理するために必要な 強力な３つのツールです これらを利用することで サーバやAppを これまで以上に 強化することができます 本日ご紹介した新機能を ぜひご利用ください フィードバックも お待ちしております 本日はご視聴 ありがとうございました 引き続きWWDCを お楽しみください [軽快な音楽]