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. Users choose the products they need to buy

3. App send payment request to App Store

4. The App Store handles payment requests. and return 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. Users choose the products they need to buy

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. server receives receipt and sends to app Stroe to verify receipt validity

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. The built-in mode does not specifically validate the transaction receipts, and the server mode uses a separate server to verify the transaction receipts.

Built-in mode is simple and quick, but easy is cracked. The server mode process is relatively complex, but relatively secure.

At the beginning of the development, Apple was very responsible for informing us that our server was not stable. After the real development. The discovery of Apple is indeed very responsible, not only unstable, but slow enough. App Store server verifies that a receipt requires 3-6s time.

1. Whether the user can tolerate 3-6s waiting time

2. Assuming the App Store server goes down, how to ensure that users who pay 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, when the server receives the client's request, it puts the request into MCQ.

For the second issue, because the Apple staff is very responsible for informing: our server is unstable. Therefore, the receipt verification timeout is not excluded. For the receipt of the validation timeout, save to the database and mark the timeout as validation. Timed tasks go to the app store at regular intervals to verify that you can get the results of your receipts.

In the development process, it is necessary to test whether the application can be properly paid. However, it is not possible to make actual payments, so it is necessary to use the sandbox store provided by Apple for testing.

The Store kit cannot be used in the iOS emulator. 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 identifies through the Issandbox field whether the receipt delivered by the client is a receipt in the sandbox environment or a receipt in the production environment.

Before submitting an Apple review. There is no problem with the sandbox test. After submitting an apple audit. Was told that the purchase failed and 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. But when a client colleague submits an Apple audit to the app. Writes the Issandbox field to death. Set as a production environment. This causes the sandbox receipts to be sent to Https://buy.itunes.apple.com/verifyReceipt to verify.

So how to voluntarily identify the receipt is the sandbox receipt it?

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

1. According to receipt field environment = sandbox.

2. Verify the status code returned from the interface according to the receipt, assuming status=21007. Indicates that the current receipt is a sandbox environment receipt, 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 a 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 for verification

The first production of verification test certificate, you can avoid the trouble of switching interfaces back and forth.

The test certificate only needs to use you to apply the test AppID time only then will use, the user does not have the test AppID, therefore does not go to the test verification this step.

Even if a production validation error occurs, you should not return the 21007 status again. Test pass username, and recharge the amount of the best use of database records, convenient company funds check.

iOS in-purchase payment server Authentication Mode