StoreKitの正常な決済の流れ

まずは、StoreKitを使った正常な購入の流れを確認していきます。

二つのモデル

In App Purchase Programming GuideではStoreKitを使ったアプリ内課金の流れとして、二つのモデルが紹介されています。購入情報を自前のサーバーで管理するサーバープロダクトモデルとアプリ単体で完結する組み込みプロダクトモデルです。サーバープロダクトモデルは流れがより複雑なので、まずはシンプルな組み込みプロダクトモデルの方で主要な部分を確認していきます。

組み込みプロダクトモデルの決済フロー

組み込みプロダクトモデルの決済フローをざっくりと見ると、下記のような手順になります。

  1. プロダクトの最新情報を取得しにいく
  2. 支払いをリクエストする
  3. 決済の結果を待つ
  4. トランザクションを完了させる

細かい処理はいくつかあるものの、正常系だけを見ればStoreKitを使った決済の仕組みはとてもシンプルです。In App Purchase Programming GuideのAdding a Store to Your Applicationには「Your application cannot create a payment request unless you have first retrieved the product information for that product.」という一文があり、「支払いリクエストをする前に必ずプロダクトの情報をとりにいけよ」と書いてあるため、基本的にはそれに従います。この部分については、また後で詳しく見ていきます。
支払い(Payment)のリクエストがStoreKitに渡されると、トランザクションが開始されます。必要に応じてApple IDを尋ねるダイアログがでて、購入確認のダイアログがでて決済が進んでいきます。この流れは基本的にStoreKitが勝手に進めてくれます。
決済が成功したらそれがアプリケーション側に通知されるので、アプリケーションは購入されたコンテンツをアンロックする等適宜購入に紐づいた処理を行った後、そのトランザクションが完了したことをStoreKitに報告します。これで一連の流れが完了です。
ここまで、正常系を実装するのは実際とても簡単です。問題は異常系の対応です。種類が非常に多く、また要素が絡み合ってくるので一つずつ見ていきます。流れにそって、プロダクト情報を取得するところから見ていきましょう。

Pocket

「StoreKitの正常な決済の流れ」への1件のフィードバック

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です