iOS in-purchase verification

After a client has successfully purchased in a sandbox environment, two validations are required

Reference from: http://www.himigame.com/iphone-cocos2d/550.html

When an app requests a successful purchase from an Apple server, Apple returns the data to the app as follows:

Product Identifier: Products Identifier [Product IDs defined within the itunes Store app, such as COM. Company name. Product Name. Item name (COM.XXXX.VIDEO.VIP)]

Trading Status: State

Purchased	Purchase success
Restored	Restore purchase
Failed	Failed
Deferred	Wait for confirmation, child mode needs to ask parental consent
Receipt	A long string, about 49 lines, as an important basis for two validations

Trade identifier: Transaction Identifier

In our company's test server, we connect to Apple's test server (Https://sandbox.itunes.apple.com/verifyReceipt) authentication.

On the official servers we deploy online, we connect to Apple's official server (HTTPS://BUY.ITUNES.APPLE.COM/VERIFYRECEIPT) authentication.

When we submit the application to the Apple audit, Apple is also in the sandbox environment to purchase, the resulting purchase voucher, but also can only connect to Apple's Test authentication server, so we can first send to Apple's official server authentication, if Apple returns 21007, then once again connected to the test server to verify.

The following is an example of the data sent to the Apple test server:

ISN:url:https://sandbox.itunes.apple.com/verifyreceiptORIGINAL JSON: {"Receipt":    {"Original_purchase_date_pst":"2015-06-22 20:56:34 america/los_angeles",//Purchase time, Pacific Standard Time        "Purchase_date_ms":"1435031794826",//Purchase time milliseconds        "Unique_identifier":"5BCC5503DBCC886D10D09BEF079DC9AB08AC11BB",//Unique identifier        "original_transaction_id":"1000000160390314",//original transaction ID        "Bvrs":"1.0",version number of the//iphone program        "transaction_id":"1000000160390314",//Identification of the trade        "Quantity":"1",//Quantity of goods purchased        "Unique_vendor_identifier":"aeec55c0-fa41-426a-b9fc-324128342652",//Developer Transaction ID        "item_id":"1008526677",the string used by the//app store to identify the program        "product_id":"COSMOSBOX.STRIKEHERO.GEMS60",//Identification of the product        "Purchase_date":"2015-06-23 03:56:34 etc/gmt",//Purchase time        "Original_purchase_date":"2015-06-23 03:56:34 etc/gmt",//Original purchase time        "Purchase_date_pst":"2015-06-22 20:56:34 america/los_angeles",//Pacific Standard Time        "Bid":"Com.cosmosbox.StrikeHero",bundle identification of the//iphone program        "Original_purchase_date_ms":"1435031794826"//MS},"Status": 0//status code, 0 for success}

Explanation of the Apple return status code: https://developer.apple.com/library/ios/releasenotes/General/ValidateAppStoreReceipt/Chapters/ Validateremotely.html

Status	Describe
21000	The APP store cannot read the JSON object you provide
21002	There is a problem with Receipt-data domain data
21003	Receipt cannot pass validation
21004	The shared secret provided does not match the shared secret in your account
21005	Receipt server is not currently available
2160p	Receipt is legitimate, but the subscription has expired. When the server receives this status code, the receipt data is still decoded and sent together
21007	Receipt is a sandbox receipt, but it is sent to the production system for verification services
21008	Receipt is a validation service that produces receipt, but sends it to sandbox environments.

For more details, please refer to: http://www.2cto.com/kf/201504/389224.html

It is better to key a database on the client, track the status of the order, to prevent the user order in a certain aspect of the problem can not find the order to do two times processing.

When you go to AppStore to request data, sometimes errors occur, and you can connect us in itunes Connect to write email feedback questions. But most of the time you have to wait and you can solve it. Maybe he'll be fine that day.

3. Background Server Authentication

There are two modes of payment in IOS:

1) built-in mode

2) Server Mode

The process of built-in mode can be summarized in the following steps simply:

1) app to get product information from App Store

2) The user chooses the product which needs to purchase

3) app send payment request to App Store

4) The App store handles payment requests and returns transaction information

5) The app will show the content of the purchase to the user

The main process for server mode is as follows:

1) The app gets a list of product identities from the server

2) app to get product information from App Store

3) The user chooses the product which needs to purchase

4) app send payment request to App Store

5) The App store handles payment requests and returns transaction information

6) The app sends transaction receipt to the server

7) The server receives the receipt and sends it to the app Stroe to verify the validity of the receipt

8) The App Store returns the verification result of the receipt

9) based on the results returned by the App Store, determines whether the user purchased the success

The difference between the above two modes is mainly: Receipt verification of transactions, built-in model does not specifically verify the transaction receipts, and the server mode will use a separate server to verify the transaction receipts. Built-in mode is simple and quick, but easy to crack. The server mode process is relatively complex, but relatively secure.

At the beginning of the development, Apple was responsible for informing us that our servers were not stable. After the real development, Apple was found to be responsible, not only unstable, but slow enough. App Store server verifies that a receipt takes 3-6s time.

1. Can the user endure 3-6s waiting time

2. If the App Store server goes down, how to ensure that users who have paid successfully will get regular service.

For the first question, we have reason to believe that the user is completely unbearable, so in the way of asynchronous authentication, the server receives the request from the client and puts the request into MCQ.

For the second issue, because the Apple staff is very responsible for the notification: Our server is not stable, so do not exclude the receipt verification timeout situation. For receipts that validate timeouts, are saved to the database and marked as a validation timeout, timed tasks go to the app store at regular intervals to verify the results of receipt validation.

iOS in-purchase verification