WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
What's new in App Store server APIs

What's new in App Store server APIs

App StoreStoreKitServer API
元の動画を見る

ハイライト

Apple は、WWDC23 で Get Transaction Info エンドポイントを App Store サーバー API に追加し、サブスクリプション ステータス フィールドとonlyFailures フィルターをNotifications V2 に追加し、verifyReceipt と Notices V1 を正式に放棄し、開発者がより最新の JWS 署名データ システムに移行することを促進しました。

主な内容

単一トランザクションを直接クエリするには、transactionId を使用します。

以前は、サーバー上のトランザクションを検証するには、Get Transaction History を呼び出してから、結果の複数ページを調べて一致するレコードを見つける必要がありました。ユーザーの取引履歴が長い場合、このプロセスは遅くて面倒です。さらに厄介なことに、完了した消費トランザクションはトランザクション履歴の取得の応答に表示されず、消費トランザクションを検証することができなくなります。

(03:12) Apple は、新しい Get Transaction Info エンドポイントを導入しました。トランザクションの署名情報を直接取得するには、transactionId を指定するだけです。完了した消費トランザクションを含む、すべてのタイプのトランザクション ID がサポートされます。

呼び出し方法は非常に簡単です。

GET https://api.storekit.itunes.apple.com/inApps/v1/transactions/{transactionId}

応答には次の内容が含まれますsignedTransactionInfoフィールドでは、デコード後にトランザクションの完全な情報を表示できます。

(06:32) もう 1 つの便利なアップデートは次のとおりです: 本来は必要ですoriginalTransactionIdパス パラメーターとしてのコア エンドポイント (例: トランザクション履歴の取得、すべてのサブスクリプション ステータスの取得) は、任意のtransactionId。最初に ID を変換するために Get Transaction Info を使用する必要はなくなり、ID を直接呼び出すことができます。

購読状況が一目瞭然

(07:42) サブスクリプション ステータスの追跡は、サブスクリプション ベースのアプリケーションの中核的な要件です。通知 V2 は、サブスクリプションのステータスが変化するとイベントを送信しますが、一部の通知タイプは現在のステータスを直接伝えることができません。

たとえば、返金通知を受け取った場合、サブスクリプションが取り消されたかどうかを直接判断することはできません。ユーザーが同じoriginalTransactionIdで新しい更新トランザクションを実行している場合、サブスクリプションのステータスは依然としてアクティブである可能性があります。届出データだけでは正しい判断をすることはできません。

(10:22) Apple が通知 V2 に新しいデータ オブジェクトを追加しましたstatus分野。これは、サブスクリプションの 5 つのコア状態の 1 つを直接表す整数です。自動更新サブスクリプションに関連するすべての通知にはこのフィールドが含まれるため、サーバーはステータスを確認するために追加の API 呼び出しを行う必要がなくなりました。

失敗通知のみを取得する

(11:36) サーバーに障害が発生すると、App Store が通知を正常に送信できない可能性があります。通知履歴の取得エンドポイントを使用すると、過去 6 か月間の V2 通知をリクエストでき、これを使用して見逃した通知を回復できます。

ただし、問題は、サーバーが正常に実行されている場合でも、一時的なネットワークの問題により、個々の通知を見逃す場合があるということです。この場合、クエリを実行するための明確な時間枠がなく、受信した多数の通知を調べて欠落を見つけることしかできません。

(12:30) Apple は、通知履歴の取得に新しいものを追加しましたonlyFailuresリクエストフィールド。有効にすると、応答には、再試行中の通知など、サーバーに正常に配信されなかった通知のみが含まれます。

リクエスト例:

{
  "onlyFailures": true
}

応答内の各通知エントリには次のものが含まれます。sendAttempts各送信試行の結果を記録する配列。以降の再試行が成功すると、通知は表示されなくなります。onlyFailuresクエリ結果に表示されます。

verifyReceipt は正式に廃止されました

(14:44) Apple は、verifyReceipt エンドポイントと App Store Server Notices V1 が正式に非推奨になったことを発表しました。これら 2 つの API は、新機能のアップデートを受信しなくなります。

App Store サーバー API への移行には、次の 3 つの手順が必要です。

  1. アプリの ID を表す JWT を生成します
  2. 各ユーザーのtransactionIdを保存します。 3.transactionIdを使用してコアエンドポイントを呼び出します。

通知 V2 への移行は簡単です。

  1. V2 形式を解析するためにサーバーを準備します (サーバー API と同じ JWS トランザクション形式を使用)
  2. App Store Connect で通知設定を V1 から V2 に切り替える
  3. 最初にサンドボックス環境で V2 通知をテストします

(19:35) Apple は、Swift、Java、Node.js、Python をサポートするオープンソース ライブラリである App Store サーバー ライブラリもリリースしました。これにより、開発者はより簡単に API を呼び出し、署名データを検証し、レシートからトランザクション ID を抽出して移行を簡素化できます。

＃＃詳細

トランザクション情報の取得エンドポイントの詳細

(05:47) 新しい Get Transaction Info エンドポイントは、個々のトランザクションのサーバー側検証の問題点を解決します。

リクエスト形式:

GET /inApps/v1/transactions/{transactionId}
Authorization: Bearer {JWT}

応答形式:

{
  "signedTransactionInfo": "eyJhbGciOiJFUzI1Ni..."
}

キーポイント:

  • signedTransactionInfo署名されたトランザクション データは JWS 形式ですか
  • デコード後、productId、purchaseDate、type などを含む完全なトランザクション情報を取得できます。
  • すべてのトランザクション タイプをサポートします: 消耗型、非消耗型、自動更新サブスクリプション、非更新型サブスクリプション
  • 完了および未完了のトランザクションをサポート

通知 V2 のステータス フィールド

(10:30) ステータス フィールドは整数で、次の 5 つのサブスクリプション ステータスに対応します。

値ステータス意味
1アクティブ購読は有効です
2期限切れサブスクリプションの有効期限が切れました
3請求の再試行請求を再試行しています
4請求猶予期間請求猶予期間
5取り消し済みサブスクリプションが取り消されました

このフィールドは、サブスクリプションの自動更新に関連するすべての通知に表示されます。返金通知を受け取った場合は、直接確認してくださいstatusコンテンツへのアクセスを無効にする必要があるかどうかがわかります。

###onlyFailures の使用シナリオ

（13:08）onlyFailuresフィールドは 2 つのシナリオを解決します。

  1. 既知のサーバー障害: サーバーがダウンした後に回復し、障害中に失われた通知をクエリします。
  2. 不明なネットワークの問題: 日々の操作中に個別の通知が失われることがあります。欠落しているアイテムをすぐに見つけます。
{
  "startDate": 1686000000000,
  "endDate": 1686086400000,
  "onlyFailures": true
}

応じてnotificationHistory配列には失敗した通知のみが含まれます。各エントリには次の内容が含まれます。

  • signedPayload：元の通知の署名内容
  • sendAttempts: 送信試行レコード、最大 6 (初回送信 1 回 + 再試行 5 回)

移行パス

(17:16) verifyReceipt から移行します。

古いプロセス:

设备 → 收据 → 你的服务器 → verifyReceipt → Apple → 解码后的收据 → 你的服务器

新しいプロセス:

设备 → transactionId → 你的服务器 → App Store Server API → 签名交易数据

Base64 でエンコードされたレシートを保存する必要はなくなり、transactionId だけを保存するだけになります。

重要ポイント

  1. リアルタイムのサブスクリプション ステータス ダッシュボードを構築します
  • やるべきこと: サーバー上でリアルタイムのサブスクリプション ステータス ダッシュボードを維持し、カスタマー サービス チームがユーザーのサブスクリプション ステータスを表示できるようにします。
  • 実行する価値がある理由: 通知 V2statusフィールドを使用すると、状態の同期が簡単かつ信頼性の高いものになり、複雑な推論ロジックが不要になります。
  • 開始方法: 通知 V2 受信エンドポイントを設定し、statusデータベース内のユーザーのサブスクリプション ステータスを更新するフィールド
  1. インテリジェントな通知回復メカニズムの実装
  • やるべきこと: サーバーの健全性チェック プロセスに統合します。onlyFailuresクエリを実行し、見逃した通知を自動的に回復します
  • 価値がある理由: ネットワークの問題は避けられません。onlyFailures見逃した通知の復元を「履歴の確認」から「正確な位置特定」に変更しましょう
  • 開始方法: サーバーの起動中またはスケジュールされたタスク中に Get notification History を呼び出して渡しますonlyFailures: true、返された欠落通知を処理します
  1. サーバー側のトランザクション検証の簡素化
  • 対処方法: 単一トランザクションの検証には、「トランザクション履歴の取得」ではなく「トランザクション情報の取得」を使用します。
  • 実行する価値がある理由: コードが単純になり、応答が速くなり、大量のトランザクション検証がサポートされます。
  • 開始方法: 既存の検証ロジックを「クエリ履歴 + 検索一致」から、トランザクション ID を渡して Get Transaction Info を直接呼び出すように変更します。
  1. verifyReceipt の移行の計画
  • やるべきこと: verifyReceipt から App Store サーバー API への移行を計画する
  • 実行する価値がある理由: verifyReceipt は非推奨になり、新しい関数は JWS 署名データ システムでのみリリースされます。
  • 開始方法: App Store サーバー ライブラリのオープン ソース ライブラリを使用して、レシートからtransactionIdを抽出し、verifyReceipt呼び出しを段階的に置き換えます。

関連セッション

コメント

GitHub Issues · utterances