3

最近、消耗品のアプリ内購入のみを行うアプリをリリースしました。多くの偽の購入に気付きました - 無効なレシートと「有効な」レシートを使用した購入ですが、Apple からの検証応答の「in_app」配列は空の配列です。ユーザーがそのような「有効な」領収書をどのように形成しているかを知る必要がありますか? アプリ内購入の領収書ではなく、アプリのダウンロードの領収書ですか?現在、検証のために次のチェックを入れています。Apple からの json 応答で「in_app」フィールドを抽出し、空でない場合は、product_id が一致するかどうかを確認します。このチェックで十分なのか、それともより優れたフールプルーフチェックなのかを知る必要があります。

4

2 に答える 2

0

このアプリ内購入に関する FAQ を参照してください。私のアプリは、購入が成功した後、paymentQueue:updatedTransactions: を介して App Store で領収書を検証します。ただし、返された領収書には、予期された製品ではなく、空の in_app 配列が含まれています。

空の in_app 配列は、App Store がユーザーのトランザクションをまだ記録していないことを示します。申請受付がまだ更新されていない可能性があります。これが発生した場合、アプリは、領収書が最新のものではないことをユーザーに通知し、更新するかどうかを尋ねることができます。

消耗品に関する情報は、支払い時に領収書に追加され、取引が完了するまで領収書に残ります。トランザクションを終了すると、この情報は次回の領収書の更新時に削除されます。したがって、アプリが消耗品のみを販売している場合、in_app 配列は空になります。

于 2019-08-20T11:21:51.353 に答える
0

すべてのアプリに領収書があります。IAP を購入したアプリには、レシートに in_app フィールドがあります。あなたのユーザーは偽の呼び出しを updatedTransaction メソッドにプッシュしており、あなたはレシートを取得し (IAP が原因で購入していないため)、それをサーバーに送信しています。他のユーザーは、どこかからレシートを交換する可能性があります (たとえば、30 人の泥棒のうちの 1 人が購入を行い、その有効なレシートを抽出して、29 人の共犯者に送信します)。そのレシートをデバイスに貼り付けて updatedTransactions への呼び出しをプッシュすると、サーバーは現在有効ではあるが重複したレシートを取得します。サーバーは領収書の日付をチェック *** し、それが最近のものよりも古いか、サーバーに共同送信する必要がある paymentRequest よりも古いことを発見する必要があります。(デバイス上でデコードすることをお勧めします - はるかに安全です)

*** transaction_id で重複する transaction_id を確認できました。残念ながら、restoreCompletedTransaction は元の購入と同じ transaction_id を返すため、これを行うことはできなくなりました。私はそのことを Apple に話しましたが、彼らは私を無視しました。

于 2016-05-05T01:32:44.007 に答える