iOSアプリ内決済（IAP）については、プロジェクト開発の過程で2回連絡を取りました。この記事では、開発プロセス全体を詳しく紹介します。IAP製品の支払いと検証のプロセスを紹介します。
該当シーン
IAPは、iOSシステムのモバイルゲームやWebゲームで広く使用されています。たとえば、一部のゲームでは、IAP支払いを使用して金貨や宝石が使用されています。Appleは、APPに仮想通貨取引が含まれる場合、支払いに使用できるのはIAPのみであると公式に規定しています。それ以外の場合は、APPレビュープロセス中に拒否されます。WeChat PayとAlipayを使用する日常生活のアプリケーションの多くは、実際のトランザクションに使用されるため、引き続きレビューに合格できます。さらに、Appleは仮想通貨の利益の30％を請求します。
タイプの説明
- 消耗品
- 非消耗品
- 更新不可能なサブスクリプション
- サブスクリプションの自動更新
消耗品
名前が示すように、ウェブゲームで金貨やダイヤモンドなどの消費可能な商品を使用して、アプリ内の仮想アイテムの通貨を購入できます。
非消耗品
一部の教育アプリのコースや一部のレーシングゲームのレーストラックなど、消費できない商品については、ユーザーが誤って削除したりアプリをアンインストールしたりするために使用する購入復元ボタンを使用して、そのような商品を確認して追加する必要があります。その他の理由で回復プロセス、そうでない場合、レビューのための提出は拒否されます
更新不可能なサブスクリプション
このような商品は、1か月のメンバーシップ、4分の1のメンバーシップなどの消耗品に似ています。消耗品との違いは、証明書を検証するときに共有秘密鍵を渡す必要があることです。
サブスクリプションの自動更新
このタイプの製品のオンライン紹介は比較的少なく、このタイプの製品のプロセスは他の製品とわずかに異なります。ビデオアプリの継続的な月間メンバーシップなどのアプリケーションの場合、このような製品は有効期限が切れると自動的に差し引かれます。サーバーの検証ロジックは異なります。
上記は商品タイプの紹介ですが、この支払いプロセスについては以下で詳しく紹介します
準備オーケー
iTunes Connetctのバックグラウンドで製品を作成し、サンドボックステストアカウントを確立します。IAP
テストフェーズ全体で、サンドボックステストアカウントのみを使用してIAP支払いをテストでき、資格情報の検証はテスト検証環境にのみ送信できます。
この部分は比較的単純なので、この記事では具体的な紹介はしていません。iTunesConnetctのバックグラウンドで作成し、指示に従ってください。
アプリケーションが最初のIAP開発である場合、関連製品を作成する前にAppleストアの個人情報（銀行カード情報、税関連情報）を改善する必要があり、製品をでレビューする必要があることに注意してください。次のリリース。IAP開発後、バックグラウンドで新製品を直接確認できます。
支払い確認プロセス
まず、プロセス全体を簡単に説明します。ここでは、APP開発を例として取り上げ、クライアント側での支払いのロジックと、IAP支払い全体のセキュリティを確保するためのサーバー側での検証について説明します。
全体のプロセスは大まかに
1.クライアントが製品注文を要求します
2.IAP製品IDを取得し
ます3.IAP製品クエリ
4.ユーザーが支払い
ます5.クライアントが注文番号+支払い伝票をサーバーに送信します
6.サーバーは伝票が有効かどうかを確認します
7 。結果はクライアントに返されます
。8。クライアントのビジネスロジック処理
以下では、更新不可能なサブスクリプションと自動更新サブスクリプションについて詳しく説明します。消耗品と更新不可能なサブスクリプションは類似しており、比較的単純です==
更新不可能なサブスクリプション支払いプロセス（例として1か月のメンバーシップを取り上げます）は、
最初にサーバーで注文し、バックグラウンドで作成された製品IDを携帯し、独自のサーバーで注文し、注文番号を取得して保存します成功したコールバックで
/**
下vip订单
@param params 参数 @"item_id" : @(itemID),
@param success 成功回调
@param fail 失败回调
*/
- (void)makeVipOrderWithParams:(NSDictionary *)params
success:(RequestOrderSuccess)success
fail:(RequestOrderfailBlock)fail;
注文が正常に完了すると、製品が支払われます。支払プロセス中にネットワーク上に多くのデモがあり、説明はありません。詳細については、githubのツールクラスIAPHelperを参照してください。
/**
购买对应商品identifier后的回调
@param identifier 商品identifier
@param completion 回调
*/
- (void)payProductsWithIdentifier:(NSString *)identifier
completion:(IAPbuyProductCompleteResponseBlock)completion;
ユーザーが正常に支払うと、コールバックで証明書が取得され、サーバーは証明書の注文番号とユーザーuidをパラメーターとして要求され、サーバーは証明書がAppleサーバーに支払われているかどうかを確認します。
/**
查询vipIAP支付结果
@param orderID 订单ID
@param receipt 凭证
@param uid 用户uid
@param success 成功回调
@param fail 失败回调
*/
- (void)requestIAPResultWithOrderID:(long long)orderID
receipt:(NSString *)receipt
uid:(NSString *)uid
success:(RequestQuerySuccess)success
fail:(RequestQueryFail)fail;
ここで、サーバー認証資格情報は、非更新サブスクリプションの支払いのため、認証のために上記の共有キーと証明書を持ち込む必要があるため、検証結果は注文のApple詳細を返し、サーバーは
クライアントの情報に従ってサービス処理に戻ります検証結果を受け取ったら、インターフェイスを更新してプロセス全体を完了します
自動更新サブスクリプション支払いプロセス（継続的な月額サブスクリプション）
支払いプロセスは上記と同じです。別の特別な処理は、検証が成功した後にサーバーがユーザーの証明書を保存することです。この段階でユーザーのメンバーシップが期限切れになると、ユーザーは証明書を再度照会します。特定のリクエスト結果に応じて、クエリ証明書が変更されます。ユーザーのメンバーシップを1か月延長します。それ以外の場合は、有効期限が切れたらメンバーシップをキャンセルします。
注文処理の紛失
IAPサーバーは品質を保証できないため、または自身のサーバーでの資格情報の検証に問題がある場合、注文が失われる可能性があります（ユーザーは支払いを正常に支払いましたが、バウチャーは正常に検証できません）この場合、この状況に対処できます。
ユーザーが正常に注文したら、注文とuidと証明書を保存します
/**
存储 订单&uid&凭证
@param orderID 订单
@param uid 用户uid
@param receipt 凭证
@param saveKey 储存key
*/
- (void)saveOrderReceiptWithOrderID:(long long)orderID
uid:(NSString *)uid
receipt:(NSString *)receipt
saveKey:(NSString *)saveKey;
ユーザーがサーバーへの認証に成功した後、またはネットワーク以外の理由で失敗した後、このレコードを削除し、
/**
删除 订单&凭证
@param orderID 订单
@param receipt 凭证
@param saveKey 储存key
*/
- (void)removeOrderReceiptWithOrderID:(long long)orderID
receipt:(NSString *)receipt
saveKey:(NSString *)saveKey;
このようにして、ネットワークの問題やサーバーの問題により注文が失われた場合、ユーザーが次にAPPを起動したときに注文を再度確認し、上記のプロセスを繰り返すことができます。
/**
核对支付成功但是验证失败的订单
*/
- (void)checkLocalLostVipOrder;
偽の注文処理
IAP支払いは、必然的に一部の偽造証明書の検証につながります。この点で、サーバーは証明書の検証に細心の注意を払う必要があります。当社のAPPは偽造証明書の検証を受け取りました。検証を参照できます。
1.証明書の確認後にitemIDを確認します
2.証明書が正式な環境での証明書であるかどうかを
確認します3.証明書の有効期間を確認します
4.ジェイルブレイクされたユーザーの処理について、以前に消耗品の支払いを行ったときに、ジェイルブレイクされたユーザー向けの一部のIAPプラグインはい、WeChatを介してジェイルブレイクされたユーザーに直接支払うことを選択します。後で判断ロジックが増えると、ジェイルブレイクされたユーザーに対してIAP支払いも有効になります。
レビューのニーズ
IAP監査中に、サンドボックステストアカウントとAPPテストアカウントを提供する必要があります。レビュープロセス中に、プロセス全体が正式な環境に切り替えられましたが、レビュー担当者は引き続きテスト資格情報を使用して検証します。サーバーは次のようにする必要があります。レビューフェーズで。このuidの資格情報は、引き続きテスト検証インターフェイスに移動して検証されます。それ以外の場合は拒否されます。