12

私たちは支払いのサーバー側の検証を使用しています -

  1. ユーザーが支払いを行います。
  2. ストア キット API は、トランザクションの領収書をアプリに送信します。
  3. アプリは base64 でエンコードされたトランザクション レシートをサーバーに送信します。
  4. 当社のサーバーはhttps://buy.itunes.apple.com/verifyReceiptを呼び出し、トランザクションの受領を検証します。
  5. ユーザーは有料としてマークされています。

特定のユーザーについては、サーバーでトランザクションの領収書を取得できなかったため、領収書を確認できませんでした。手順 2 と 3 で何か問題が発生したと推測されます。レシートをサーバーに送信するときに接続の問題があった場合、アプリはその後のアプリの再開時に再試行します。

これで、トランザクションの領収書が 1 つ不足し、怒っているユーザーが 1 人います。どのように前進することをお勧めしますか? 今後これを防ぐにはどうすればよいでしょうか。このような状況を防ぐために従うことができるガイドラインやベストプラクティスはありますか?

ありがとうございました。

4

1 に答える 1

4

私の経験に基づくと、考えられる問題は次のとおりです。

  • base64 データは途中で URL エンコードされたため、+ と / がめちゃくちゃになりました - 転送前にこれらをより安全な文字に置き換えてください
  • 取引全体が偽物です。

2 番目のケースを確認する方法は、アカウントを調べて、一致する購入記録があるかどうかを確認することです。残念ながら、購入量が少ない場合を除き、Web サイトを確認するのは少し難しい場合があります。

サーバーまたは発生した場合は Apple 側でエラーを正しく処理するために、コードで必要な 2 つのことです。

  1. サーバーとの通信が成功するまでは、finishTransaction: を呼び出さないでください (この場合は役に立ちませんが、注意が必要です)。
  2. SKPaymentQueue defaultQueue で restoreCompletedTransactions: を呼び出す「購入のリロード」ボタンまたはアクションを用意します。非消耗品/資格オブジェクトの場合、これにより、サーバーで再検証できる領収書を含むすべてのトランザクションが再送信されます。

直面している問題が非消耗品/権限にある場合は、2 番目のアイテムが解決策です。

于 2013-02-11T17:36:52.057 に答える