iOS 課金まとめ

参考

2019/1/1現在の日本語ドキュメントをもとに再編成しています。
最新版は英文を確認ください。
In-App Purchaseプログラミングガイド
[公式ドキュメント]
(https://developer.apple.com/jp/documentation/StoreKitGuide.pdf)
[失敗しない iOS In-App Purchase プログラミング]
(http://d.hatena.ne.jp/glass-_-onion/20111201/1322697417)
[iOS の アプリ内課金（In-App Purchase） 組込方法]
(http://amarron.hatenablog.com/entry/2014/05/24/093913)

Apple Pay

In-App Purchaseについて

StoreKitフレームワークを使用してアプリケーション内にストアを組み込む方法

販売できないもの

実物の商品やサービスを販売することはできない。
仮想通貨
ポルノ、誹謗、中傷、ギャンブルに関連するもの
ギャンブルのシミュレー ションであれば問題なし。

販売できるもの

電子商品や電子サービス
デジタルコンテンツ(電子書籍、雑誌、写真など)
機能プロダクト
機能のロック解除や拡張。

App内課金の種類

• Consumable(消耗型)
  1度だけ使え、使うたびに毎回購入するプロダクトは、Consumable(消費型)のプロダクトとして実装します。釣りアプリケーションの餌のような一度限りのサービスは、Consumableとして実装するのが普通です。

• Non-Consumable(非消耗型)
  プロダクトをユーザが1度だけ購入します。ゲームアプリケーションの新しいレーストラックのように、使っても無効になったり減ったりしないサービスは、Non-consumableプロダクトとして実装するのが普通です。
  Appleは、代理でNon‐Consumableプロダクトをホストすることができます。詳しくは、 Non‐Consumableプロダクトのホストを参照してください。

• Auto-Renewable Subscription(自動更新購読)
  ユーザは所定の期間に、雑誌の購読など、動的なコンテンツを購入できます。購読はユーザがオプトアウトしない限り自動的に更新されます。提供するコンテンツが 『アプリケーション審査ガイドライン』で概説されている内容に適合しない場合、コンテンツをNon-Renewing Subscriptionで提供することを考慮してください。
  Auto-Renewable Subscriptionには、連絡先情報を提供することを承諾したユーザへのインセンティブを含めることができます。

• Free Subscription(無料購読)
  ユーザは所定の期間に、雑誌の購読など、動的なコンテンツをダウンロードできます。Free Subscriptionは、開発者が無料で購読できるコンテンツをApp StoreのNewsstandに置くための手段です。ユーザは、Free Subscriptionにサインアップすれば、Apple IDに対応するあらゆるデバイス上で購読できるようになります。なお、Free Subscriptionは期限切れになることがないこと、Newsstand対応アプリケーションでのみ購読できることに注意してください。
  Auto-Renewable Subscriptionとは異なり、Free Subscriptionの場合、マーケティング目的で連絡先情報を提供したユーザへのインセンティブを提供できません。ただし、ユーザに連絡先情報の提供を促すメッセージは表示されます。
  Free Subscriptions はMacアプリケーションでは利用できません。

• Non-Renewing Subscription(非更新購読)
  期間を限定した項目を販売できます。Non‐Renewing Subscriptionは、静的コンテンツに時間 ベースでアクセスできる製品に使用します。
  Non‐Renewing Subscriptionを使用する場合、アプリケーションには、ユーザのApple IDに関連付けられているすべてのデバイスに定期購読を配信する責任があります。
  Non‐Renewing Subscriptionの場合、ユーザがそのつど更新しなければならないので、購読期間がいつ終わるか認識するコードと、更新手続きをするようユーザに促すコードをアプリケーションに組み込む必要があります。

実装方法

サーバプロダクトモデル

プロダクトを外部サーバに置き、決済をAppleのサーバで行い決済後にプロダクトをiPhoneアプリに渡す。外部サーバのシステムも必要となるため敷居が高く面倒。

組み込みプロダクトモデル**

プロダクトの配布に必要なすべてをアプリケーション内に組み込み、最初はロックをかけて課金後にロックを外す。外部のサーバを必要としないためサーバープロダクトモデルに比べれば簡単に実装できる。

In-App Purchaseプロセス概要

• ユーザがアプリケーションのストアに移動すると、アプリケーションのプロダクトが表示されます。
  次に、ユーザが購入するプロダクトを選択し、アプリケーションがApp Storeに支払いを要求します。
  App Storeは支払いを処理し、アプリケーションが購入済みプロダクトを配信します。
  

1. iTunes Connectでプロダクトを作成し、設定する
2. App Storeでアプリケーションによってプロダクトを販売する
3. 購読(Subscription)に必要なアプリケーションロジックを追加する
4. ユーザが購入したプロダクトを復元(Restore)する
5. アプリケーションとプロダクトを審査用に登録する

プロダクトの設定

1つのアプリケーションにつき、In-App Purchaseプロダクトを1000個まで作成できます。提供するプロダクトは、iTunes Connectで1つずつ設定する必要があります。In-App Purchaseプロダクトは、特定のアプリケーションと関連付けられているため、iTunes Connectの「App Summary」ページから作成します。

プロダクトID取得

プロダクトIDが存在するかチェックする。(com.xxx.xxx)

• アプリケーションバンドル内へのプロダクトIDの埋め込み
• サーバからのプロダクトIDのフェッチ

プロダクト情報の取得

ユーザが実際に購入できるプロダクトをAppStoreから取得

アプリケーションのストアUIの表示

Storekitには用意されていないため、アプリケーション側でUIを用意する。

ここまでのテスト

• テスト用アカウントによるApp Storeへのサインイン
• 無効なプロダクトIDの処理のテスト
• プロダクト要求のテスト

支払要求

アプリケーションがApp Storeに支払い要求を送信する。

異常アクティビティの検知

App Storeは異常アクティビティ検知エンジンを使用して不正に対応します。追加情報を提供すること
で、エンジンの異常トランザクション検知能力を向上するアプリケーションもあります。ユーザが
App Storeアカウントに加えてアプリケーションのアカウントを持っている場合、支払い要求の際にこ
の追加情報を提供してください。

支払い要求の送信

支払要求を作成し、トランザクションキューに追加すると、App Storeに送信されます。複数送信で複数回配信される。

プロモーション

iOS 11以降、App Store上でIn-App Purchaseのプロモーションが可能になりました。プロモーション対象のIn-App Purchaseは、プロダクトページに現れ、検索結果として表示されるほか、App Storeのしかるべきタブ上に大きく取り上げられることもあります。ユーザーは、App Store上でIn-App Purchaseを立ち上げた後、アプリケーションに切り替えてトランザクションを続行できます。アプリケーションがインストール済みでなければ、ダウンロードするよう指示が現れます。

概要

In-App Purchaseのプロモーションは2段階に分けて行います。

iTunes ConnectでIn-App Purchaseをセットアップします。まず、対象とするIn-App Purchaseのプロモーション画像をアップロードします。次にiTunes ConnectのApp Store Promotionsツールで、App Storeに現れる順序や表示/非表示を管理します。
SKPaymentTransactionObserverプロトコルに従い、購入手続きに必要なデリゲートメソッドを実装します。
ユーザーごとに見え方をカスタマイズすることも可能です。SKProductStorePromotionControllerメソッドで、表示/非表示や出現順序を変更できるのです。

この機能のマーケティングガイドについては、「Promoting Your In-App Purchases」を参照してください。

購入手続き

App Store上に現れたIn-App Purchaseで、ユーザーが「Buy」をタップまたはクリックすると、StoreKitは自動的にアプリケーションを開き、SKPaymentTransactionObserverプロトコルのデリゲートメソッドを介してトランザクション情報を渡します。アプリケーション側では、購入トランザクションおよびこれに関連する、アプリケーション特有のアクションを実行しなければなりません。

デリゲートメソッドは、トランザクションを続行するならばtrue、延期またはキャンセルするならばfalseを返します。

ユーザーが「Buy」をタップまたはクリックした時点でアプリケーションが未インストールであれば、App Storeはこれを自動ダウンロードし、または購入するようユーザーに促します。インストール済みであっても版が古く、In-App Purchaseのプロモーションに未対応であれば、App Storeはアップグレードするようユーザーに促します。

• トランザクション続行
• トランザクション延長orキャンセル

In-App Purchaseの提示方法をカスタマイズ

• 表示/非表示の設定の読み取り
• 表示/非表示の設定のオーバーライド
• 出現順序のオーバーライド
• オーバーライドした出現順序のキャンセル
• オーバーライドした順序設定の読み取り

公開前のテスト

itms-services://?action=purchaseIntent&bundleId=com.example.app&productIdentifier=product_name

このURLを電子メールやiMessageで自分自身に送信し、これをデバイスから開いてください。アプリケーションが自動的に開けば、プロモーション対象のIn-App Purchaseのテストを開始できる状態です。

プロダクトの配信

App Storeによる支払い要求の処理後、アプリケーションは情報を保存し、購入したコンテンツをダウンロードして、トランザクションに終了のマー
クを付けます(図 4-1を参照)。

App Storeがトランザクションを処理するのを待機する

支払い要求のほか、Appleによっ
てホストされたコンテンツのダウンロードと購読の更新の検出にもトランザクションキューを使用し
ます。

購入の持続

アプリケーションは起動時にその持続的な記録を使用して、プロダクトの提供を継続します。ま
た、購入の復元にも記録を使用します

1.Appレシートを使用した持続

User DefaultsまたはiCloudを使用した値の持続

消耗型プロダクトと非更新購読の情報は、支払いが行われるとシートに追加され、トランザクション
を終了するまでレシート上に残ります。トランザクションの終了後、この情報はレシートが次に更新
されるとき、たとえばユーザが次に購入を行ったときに削除されます。
これ以外の種類のプロダクト購入の情報は、支払いが行われるとレシートに追加され、レシートに残
り続けます。

User DefaultsまたはiCloudを使用したレシートの持続

独自のサーバを使用した持続

どのレシートがどのユーザに属しているのかを追跡できるように、ある種の証明書またはIDとともに
レシートのコピーをサーバに送信します。

アプリケーションの機能のアンロック

プロダクトによってアプリケーションの機能を有効にする場合、コードパスを有効にするためのブー
ル値を設定し、必要に応じてユーザインタフェースを更新します。

関連コンテンツの配信

プロダクトに関連付けられたコンテンツがある場合は、そのコンテンツもアプリケーションでユーザ
に配信する必要があります。たとえば、ゲームのレベルを購入するときにレベルを定義したファイル
を配信する必要がある場合、また音楽アプリケーションで追加の楽器を購入するときに、ユーザがそ
の楽器を演奏するために必要なサウンドファイルを配信する必要がある場合があります。

ローカルコンテンツのロード

ホストしたコンテンツのAppleのサーバからのダウンロード

独自サーバからのコンテンツのダウンロード

トランザクションの終了

トランザクションが終了すると、購入で必要なすべての処理が完了したことがStore Kitに通知されま
す。

テスト手順

1.支払い要求のテスト
1.オブザーバコードの検証
1.成功したトランザクションのテスト
1.中断したトランザクションのテスト
1.トランザクションが終了したことの確認

購読の取り扱い

購読の有効期間の計算

各レシートエントリの「Original Purchase Date」および「Subscription Expiration Date」フィールド
を確認し、購読の開始日と終了日を特定します。

期限切れと更新

更新プロセスは、期限切れの10日前から開始される「事前」チェックから始まります。この10日の間に、たとえば、顧客に有効な支払い方法があるかどうか、ユーザがこの購読を購入してからプロダクトの価格が上昇していないかどうか、またはプロダクトが利用できなくなっていないかどうかなど、購読の自動更新が遅れたり更新できなくなる可能性のある問題がApp Storeによってチェックされます。問題がある場合はApp Storeによってユーザに通知されるため、購読の更新が必要になる前に問題を解決することができ、購読が中断されないようにします。



キャンセル

購読の購入時には全額が支払われ、Appleカスタマーサービスにご連絡されることによってのみ払い戻されます。購入がキャンセルされたかどうかをチェックするには、レシートで確認できる。

プラットフォームをまたがる場合の考慮事項

プロダクトIDは、1つのアプリケーションに対して関連付けられています。アプリケーションにiOS
バージョンとOS Xバージョンの両方がある場合は、各プラットフォームに対して、独立したプロダク
トに独立したプロダクトIDを与えます。

復元

ユーザは購入済みのコンテンツに引き続きアクセスするためにトランザクションを復元します。
新しい端末での利用など。

Appレシートの更新

完了したトランザクションの復元

最後に申請する前のチェック事項

(1)コンテンツが規約に違反していないか
(2)プロダクトのタイプが適切か
(3)復元(リストア)機能が実装されているか
(4)仮想通貨を実装する場合、期限をもうけていないか、他アプリに引き継いでないか。
(5)レシートレシートベリファイが含まれる場合、Sandboxレシートを扱えるようになっているか
(6)課金場所がわかりやすい場所にあるか
(7)iTunesConnectの登録情報に問題がないか
(8)iTunesConnectの”メモ”に説明があるか
(9)iTunesConnectのアプリ紹介文に説明があるか

追記

追記2 ユーザ証明書不正対策(アプリ規模による)

独自サーバーでレシートに含まれているProductIdの検証が必要
http://inside.pixiv.net/entry/2014/12/09/111310

追記3

ReactNativeでもライブラリ使えばいけるっぽい
https://github.com/chirag04/react-native-in-app-utils