0

アプリ内購入機能をテストしていて、領収書の検証手順で行き詰まりました。領収書の検証はカスタマイズされており、サーバー側で処理する (サーバー API を呼び出す) チェックの数に基づいており、それらの 1 つはトランザクション ID の一意性が支払いを確認するための条件です。したがって、RMStoreを使用して領収書を正常に取得し、 addPayment 関数は一意のトランザクションを成功ブロックに返します。その後、成功ブロック内でverifyTransactionを実行し、recipeURLを呼び出します。残念ながら、receiptURL を使用して常に同じレシートを取得しているように見えます。それをサーバーに送信すると、トランザクション ID が既に DB に存在し、トランザクション ID が一意ではないというエラーが返されます。このエラーは、新しい支払いを行っても同じ領収書を送信したことを示しています。私は消耗品を使用していることに注意してください。

誰かが私が以下に提供する機能の正しいワークフローを教えてくれますか(?):

  1. [RMStore productRequest] - init 関数で直接呼び出します。
  2. [RMStore addPayment] - 理解しなければならない結果の始まりです。
  3. [[[RMStore defaultStore].transactionPersistor consumerProductOfIdentifier:pID] -- この関数を呼び出す必要はありますか? Apple は私が支払うたびに一意の transactinID を送信してきますが、この関数を呼び出しても何の影響もありません。
  4. [[[RMStore] defaultStore].receiptVerificator verifyTransaction:transaction] -- トランザクション検証を呼び出す必要がありますか?
  5. [RMStore receiptURL] または [[NSBundle mainBundle] appStoreReceiptURL] -- recipationURL を取得するこれらの方法は同じですか? どちらも期待どおりに機能しません。
  6. [NSData dataWithContentOfURL:receiptURL] - これが私が経験している主な問題です。上で述べた関数の組み合わせでさまざまな試みを行った後、このメソッドは常に同じトランザクション ID を持つレシートを返します。これにより、最後の領収書を取得するために #5、#6 を実行する前にキャッシュを更新する必要があると思われますが、その方法は明確ではありません。

したがって、RMStore wiki は良さそうに見えますが、ライブラリを使用すると、内部で何が起こっているのかを完全には理解できない可能性が常にあると思います。残念ながら、RMStore については、Apple in app purchase API がどのように機能するかを調査する必要があります。これは、関数呼び出しの結果が提供される場合に解決できますが、どこにも見つかりません (!)

誰かが私が提供した機能のリストを見直して、購入後に最後のレシートを取得する際の問題を解決できるように、それらを正しい順序で配置するのを手伝ってもらえますか?

4

1 に答える 1

0

私の質問に対する答えは 2 つあります。

  1. コード：

    NSURL *receiptURL = [[NSBundle mainBundle] appStoreReceiptURL];

    、正常に動作します (つまり、正しいレシート本文が返されます) が、何らかの理由で、Apple は最初のトランザクション ID が以前に取得したものと同じである場合に 2 つ (または配列 []) の支払いを返すことができます。私のサーバー開発者が言ったように、これは予期しない動作です。そのため、レシートを取得してサーバーにレシートを送信すると、以前に取得したものと同じ最初のトランザクション ID のみが読み取られます。その結果、サーバーは検証結果として FALSE を返します (2 回支払いを試みているようです)。Apple が領収書に 2 つ以上の取引記録を送ってきた理由は明らかではありません。、しかし回避策として、サーバー側の開発者に、受信中のすべてのトランザクションを確認して一意のトランザクションIDを確認するように依頼しました。Apple の動作を理解するにはさらに調査が必要ですが、さらに時間がかかる可能性があります。答えが見つからなかったので、とりあえず先に進みます。

  2. RMStore ワークフローに関連するもの 実際には、addPayment と verifyTransaction という 2 つの最も重要な関数しかないことに気付きました。addPayment 関数は、verifyTransaction を暗黙的に呼び出します。verifyTransaction をオーバーロードし、内部で serverAPI 検証関数を呼び出す必要があります。したがって、検証が成功した場合は、addPayment の成功ブロックに移動し、支払いを成功させるために必要なことを行います。そうでない場合は、何か他のことをしてください。私の間違いは、addPayment 成功ブロック内で verifyTransaction を呼び出すことでした。これは、2 回呼び出すことを意味します。

于 2016-02-25T12:56:23.067 に答える