iOSにおいて、Unity IAP を使って課金処理を実装しました。色々なサイトを参考にさせていただいたのですが、実装してみないとわからない点が多くありましたので、複数回に分けて記事にまとめます。
- In App Purchasing
4.1.2 - Unity
2020.3.21.f1 - iOS
iPhone SE 15.1
iPad mini （第五世代） 15.2
この記事ではIAPの実装についてまとめます。 セットアップ・課金機能概要、評価についてはこちらの記事を参照してください。
ストア環境の準備
iOSでの購入評価はSandbox環境（評価用の隔離された環境）で評価します。そのための App Store Connect 設定について説明します。
Sandboxテスターの追加
App Store ConnectのユーザーとアクセスからSandbox環境のテスターを追加します。ユーザーとアクセスを選択して左下のテスターを選択、+ボタンでユーザーを追加します。
テスターの情報入力ダイアログが出ます。メールアドレス含め、全て適当で構いません。ただし、このアカウントでストアに接続することになるので、すでに存在するアカウントではNGとなります。
メールアドレスにはアプリのバンドル名＋日付＋通し番号@XXX.comのような重複しないアドレスを指定するとよいです。なぜこのようなアドレスにすると便利かというと、後述する購入履歴の消去機能がザルで、履歴が消せたのか、消せてないのか、そもそも購入履歴が反映されていないのか否か、知るすべがなく、購入履歴を消すより新しいアカウントを追加して評価した方が確実で早いからです。
たびたび追加するので、いつ追加したのかなどがわかる方がよいので、このように一つに決まるアドレスをお勧めします。また、ある程度溜まったら定期的に削除する必要があります。
ただ、一度削除したアドレスはなぜか再度テスターに追加できませんでした。本当に使いづらいです。
アイテムの追加
課金アイテムはApp Store ConnectのAppメニューから該当アプリを選択して左のApp内課金→管理から追加します。
ステータスが承認済みになっていますが、未審査のアプリは承認済みになっていません。ただ、承認されていなくても評価は可能です。
＋ボタンから課金アイテムを追加します。以下のようなアイテムの種類を選択するダイアログが表示されるので、追加したいアイテムを選択します。ここでは非消費型を選択しました。
課金アイテムの情報を入力していきます。参照名は自分で区別するためのものなので、適当で構いません。製品IDはコードに埋め込む製品IDになります。
価格はAndroidと異なり、ある程度決められた中から決定します。
ストア情報はストアに表示される情報です。タイトルと説明を記載します。複数言語にローカライズしている場合はローカリゼーションを追加して記載します。
一通り入力したら上段の保存ボタンで保存します。
契約 / 税金 / 口座情報の設定
アプリから課金をテストするためには口座情報や税金に関する入力を完了している必要があります。全てActiveになるように設定してください。設定方法は他の多くのサイトで紹介されていますので、ここでは省略します。
iOSの準備
iOSはアプリを起動し、購入処理を行おうとするとApple IDが求められます。そこに先ほど追加したテスターのアカウントでログインします。ログインに成功すればSandbox環境での購入が評価できます。
購入ダイアログには[Environment : Sandbox]と表示されていれば成功です。
テスト手順の奨め
リストアの確認
非消費型のアイテムがある場合、ユーザーに対して購入より先にリストアを要求ようなアプリの実装にするのがよいです。なぜなら、購入済みのアイテムを購入しようとしても、すでに購入済みとなり、アイテムをリストアするかどうかのダイアログが表示されるからです。
ライブラリを初期化してレシートがなかった場合はリストアを促し、ユーザー操作によるリストアを評価するようにします。
Storeに購入履歴があれば、リストア後、 ProcessPurchase()がコールバックされレシートが復元されます。購入履歴がなければ何もコールバックはないので、購入を促します。
購入処理
環境で設定できる購入処理のパターンは正常に購入が完了する場合と、購入を中断される場合とユーザーによる購入キャンセルなどです。
正常に購入が完了する場合とユーザーによるキャンセルは手元の操作で評価できます。
購入を中断されるパターンはStoreで設定が必要となります。前述の ストアメニューのユーザーとアクセスからテスター一覧を表示し、選択すると、以下のように購入中断設定が選択できます。
ここでこのテスターの購入を中断するにチェックを入れておけば、決済時に中断されます。中断はOnPurchaseFailed()で通知されるので、正しくエラーハンドリングできていることを確認します。
返金の確認
実装編でも説明しましたが、RefreshAppReceipt()を実行しないと返金によるレシート消去がうまく同期されませんでした。一度か二度、ライブラリの初期化でレシートがなくなったのですが、いまいち確証が持てません。RefreshAppReceipt() の実行中にタスクキルするとアプリが起動しなくなる現象に何度か出くわしたので実装はしていません。
ただ、アプリを削除して再インストール→リストア実行でレシートがなくなっていることは確認できます。これはアプリを削除さえしなければレシートは残り続ける→サービスを利用し続けることができるということになるので、微妙ですが。
返金はSandboxテスター一覧の編集ボタンから実行できます。これもいまいちで、レシートが消えたのか消えてないのかがわかりません。
返金に関しては課題が残りますが、おそらく真面目に実装している人はサーバーを準備してそこからストアに問い合わせる仕組みを組んでいるので、解決できているのだと思います。
評価の時の注意点
２回購入画面が表示される
購入を一回終わらせた（チャリーンのSEあり）ところで、購入完了せず、もう一度購入画面が表示される現象が何度も確認されました。調査したところ、Sandbox環境固有の現象のようです。
しかも、操作は特になにもしていないにも関わらず、ユーザーによるキャンセルという購入エラーがコールバックされました。
本番環境では起きないようなのですが確認できていないので、決済が失敗したこと（二重課金にはならないこと）を明確に表示しておく方がユーザーにも安心かと思いました。
RefreshAppReceiptで起動せず
RefreshAppReceiptはそこそこ時間のかかる処理のようです。初期化時に実行していたのですが、その実行中にタスクキルなどでアプリを終了させると、たまにアプリが全く起動しなくなる現象を確認しました。
RefreshAppReceipt が100％原因とは言い切れませんが、以下の理由で RefreshAppReceipt は危険と判断しました。
- 処理を外すと現象が収まる
- アプリが起動しない時はInAppPurchaseのライブラリの初期化処理で刺さる
- アプリを終了しないと現象は発生しない
怖いので、 RefreshAppReceipt は使用しないようにしています。
おわりに
iOSはアプリをストアに登録することなく、Sandbox環境でテストできるのは便利です。一方、本番環境と厳密には動作が異なる点や、課金、返金の管理が困難な点、それに伴い、テストアカウントが山のようにできる点などテスト環境の使い勝手は悪いです。
年間１万以上集金しているのだから、きちんとしていただきたいですね。
コメント