1

消耗品をユーザーに返す前に、とりわけ (API 呼び出しを介して) サードパーティから何かを購入する必要があるサーバーがあります。明らかに、事前にAppleのレシートをチェックします。

サーバー側のアプリ内障害に対処する最善の方法は何ですか?たとえば、サードパーティのサービスが失敗した場合はどうすればよいですか? この時点で、ユーザーの経験は、支払ったが消耗品を受け取っていないというものであり、再試行するとより多くのお金を費やすことになります.

これまでのところ、私は思いついた：

デバイス上

  1. inapp が完了したら、その productId のレシートを「unclaimed」として保存します
  2. いつものようにサーバーに連絡してください。
  3. 成功した場合は、請求されていない領収書/productId をクリアします
  4. エラーが発生した場合、次にユーザーがアプリ内で同じことを試みると、実際の購入部分をスキップして、前のレシートを使用して 2. に直接進みます。

次に、サーバーで

  1. Apple で領収書を確認する
  2. そのレシートの消耗品をユーザーにまだ提供していないことを確認します (レシートの再利用を防ぎます)。
  3. サードパーティに電話をかける
  4. 成功すると消耗品を返します。
  5. 失敗した場合は、エラーを返します (この時点で、クライアントは領収書を請求されていないものとして保持し、再試行時に再送信します)。

前もって感謝します！

4

2 に答える 2

0

私が理解している限り、あなたの主な問題は消耗品の購入に関連する UI/UX にあります。

あなたの消耗品がどのようにユーザーに「表示/使用可能」になるかはわかりませんが、サーバーとのトランザクションが「一時的な失敗」状態になったことをユーザーに明確にすることが重要です。これは、アプリのダウンロードに障害が発生したときに App Store で発生するのと同じです。「読み込み中/待機中」としてマークすることができ、「購入」の代わりに、消耗品をダウンロードするだけでよいことを明示できればよいでしょう (「購入」ではなく「インストール/再試行/ダウンロード/回収」)。 ）。

同じ場所に「問題が発生した場合に連絡する」オプションがあることも非常に良いでしょう. サードパーティの接続が失敗する理由はわかりませんが、散発的ではない方法で失敗する場合は、2 人以上のユーザーが文句を言う必要があるに違いありません.

質問のクライアントサーバープロトコル側に関しては、あなたの説明は私には良いようです。ここでの重要なポイントは、サーバーが、どのレシートが既に正常に請求されたかを追跡することです。原則として、クライアントは必要に応じて何度でもレシートの再利用を試みることができますが、最初の試行でのみ成功します (サーバーがレシートを配信済みとしてマークする前)。回復力がさらに必要な場合は、クライアントからサーバーへの明示的な確認フェーズを導入して、消耗品が正常に処理されたことを確認します。

それが役に立てば幸い。

于 2013-01-30T09:26:04.943 に答える
0

私のアプローチは、それを一種のトランザクションにすることです
。ステップ2を2a、2b、2c、および2dに分割し、クライアントサーバーを関与させます

サーバ：

=> 2a = 領収書を使用していないことを確認します (使用済みおよび配送済み商品の内部データベースで)
-> 使用していない場合は配送します

クライアント：

-> 購入して 2b を実行
=> 2b サーバーにデータを受信したことを伝えます!

サーバ：

=> 2c: クライアントの確認を待ちます => 2cd= 領収書を配達したので、領収書を (データベースで) 焼き付け済みとしてマークします

于 2013-01-30T08:59:46.787 に答える