The receipt of Apple internal purchase server verification returns multiple groups In_app thinking

Recently, some users reflect that Apple has failed to recharge the top-up, after testing a summary of several key points have problems

1.app purchase Success The Apple does not return the ticket, belongs to the ticket omission (depends on the Apple server's response condition), only the client listens to refresh and so on processing

2.app continuous purchase process, the previous several times the Apple did not return the ticket, a few times after the Apple returned a valid ticket, the app submitted to the server to verify the process of In_app in the case of multiple sets of data, this situation is still able to recharge the success, but not all to the account

3.app continuous purchase, there is a normal return of the ticket, in the process of submitting to the server unexpectedly, but the actual service side has accepted the ticket, for the user to recharge successfully, but the next time the app recharge with the ticket, again submit the server verification, In_app in the last submitted note information, In this case the server will be judged to have been recharged, causing the last reload to fail

In the spirit of inquiring, review the information summarized below, Apple's official description (IAP ticket verification) is as follows:

Baidu translation is as follows:

It says that the ticket in a JSON file, is an array containing all the application purchase receipts based on the application purchase transaction receipt data input Base-64, and it is possible to return an empty array (an empty array is actually still valid)

When you add an application purchase receipt to a consumable product to an invoice purchase, it is saved in your application to receive the completed transaction. At this point, it is the next time you receive an update-for example, from a receipt, when the user buys it again or if your application explicitly refreshes the receipt.

Forgive me the low level of English, after reading a face confused force, the following summarizes my personal understanding, the general meaning is as follows:

The purchase of a consumable product is added to the ticket information after the purchase is complete (Apple's purchase is complete, not the server purchase) until your app finishes trading (the app's active behavior), and then it refreshes the ticket when the user next buys it, or the app displays the refresh.

Reading this will be a good understanding of the above problems, that is to say:

Verify the In_app field in the receipt returned by the ticket, which contains all the ticket information for the transaction that you have not completed. That is, after the app has finished trading, the ticket information disappears from the In_app.

If the app does not complete the transaction, the ticket information will remain in the In_app. (This condition may be limited to your product type is consumption type)

Knowing the story of the incident, it is very good to optimize the solution, the scheme has 2

1. The In_app data of the return of the ticket is processed, all of which do not recharge

2. Only the latest recharge information is processed (the plan we take)

Because of the adoption of a scheme:

If the user has only a one-time recharge, the top-up is not credited, he no longer recharge, then will not be able to cause.

If he has been replenished through the customer service channel, then he will continue to recharge the next time the product is still brought back, when there may be repeated recharge the situation

Special NOTE: If you need a unique number of the current ticket, take the transaction_id of the last ticket in In_app.

by Hgq

The receipt of Apple internal purchase server verification returns multiple groups In_app thinking