iOS in-purchase payment server Authentication Mode

Two modes of purchase in IOS:

• Built-in mode

• Server mode

The process of built-in mode:

1. App to get product information from App Store

2. The user chooses the product to be purchased

3. App send payment request to App Store

4. The App Store handles payment requests and returns transaction information

5. The app will show you what you've purchased

Process for Server mode:

1. 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 to be purchased

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. App Store returns validation results for receipts

9. Depending on the results returned by the App Store, the user is successfully purchased

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 can 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.

In the development process, it is necessary to test whether the application will be able to make a normal payment, but cannot make a real payment, so it needs to use the sandbox store test provided by Apple. The store kit cannot be used in the iOS emulator, and the test store must be on the real machine.

在sandbox中验证receipt:
https://sandbox.itunes.apple.com/verifyReceipt

在生产环境中验证receipt:
https://buy.itunes.apple.com/verifyReceipt

During the actual development process, the server side through the Issandbox field identifies whether the receipt passed by the client is a receipt in the sandbox environment or a receipt in the production environment. There is no problem with sandbox testing until the Apple review is submitted. After submitting the Apple audit, was told the purchase failed, the audit did not pass. The query log found that the transaction receipt sent by the client was a sandbox receipt, but the Issandbox field was identified as a production environment.

Conclusion:

When Apple reviews the app, it still tests in a sandbox environment. However, the client colleague writes the Issandbox field to the production environment when the app submits an Apple audit. This causes the sandbox receipts to be sent to Https://buy.itunes.apple.com/verifyReceipt to verify.

So how to automatically identify whether the receipt is a sandbox receipt it?

There are two ways to identify receipts in a sandbox environment:

1. According to the receipt field environment = sandbox.

2. Verify the status code returned by the receipt verification interface, if status=21007, indicates that the current receipt is the receipt for the sandbox environment and T is validated.

Status code for Apple feedback;

• 21000APP Store cannot read the JSON data you provide
• 21002 The receipt data does not conform to the format
• 21003 receipts cannot be verified
• 21004 the shared key you provided is inconsistent with the shared key of the account
• 21005 the receipt server is not currently available
• 21006 the receipt is valid, but the subscription service has expired. When this message is received, the decoded receipt information is also included in the returned content
• 21007 Receipt information is test (sandbox), but is sent to the product environment to verify
• 21008 The receipt information is used in the product environment but is sent to the test environment to verify

Production verification after the test verification, you can avoid the trouble of switching interfaces back and forth. Test validation will only be used if you use your own test AppID, the user will not have the test AppID, so will not go to the test to verify this step. Even if a production validation error occurs, you should not return the 21007 status again. Test verification through the user name, and the top-up amount of the best use of database records, convenient company funds check.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

In-iOS purchase Payment server Authentication Mode