payment method

IAP refers to In-App Purchase, which is a payment method, not Apple’s proprietary payment method. There will be different implementations on other platforms, and this is for Apple IAP. Speaking of IAP security issues, there is an obvious logical loophole in Apple’s IAP process. This logical loophole is based on our improper handling, which will cause problems between the services provided by our own side and users. First look at the IAP payment sequence diagram:

payment process

1. The client requests the Appstore to purchase the product (assuming the product information has been obtained), and the Appstore will deduct the fee from the user’s Apple account balance after the product is successfully verified.
2. Appstore returns a piece of receipt-data to the client, which records the certificate and signature information of this transaction.
3. The client provides receipt-data to the server we can trust
4. The server performs a base64 encoding on the receipt-data
5. Send the encoded receipt-data to itunes.appstore for verification

6.itunes.appstore returns the verification result to the server

7. The server issues corresponding props and push data update notifications to the client for the purchase status of the product and the type of product
8. The client receives the processing status of the server and performs corresponding statement processing

These eight steps are actually a very safe process. So where is the problem? Let’s talk about two authentication models for Apple’s IAP

Ways of identifying

1.IAP built-in Model, local verification

Some apps and even online games directly skip steps 3~7. After getting the receipt-data in step 2, the client sends a verification request to itunes.appstore directly, gets the result, and modifies the data according to the result.

When we design APP, we follow a truth, “any data on the client side is not safe”, and we take it for granted. If there is no independent server to assist verification, the fact that the data is modified cannot be avoided, and yes, you will make less money.

However, if the APP does not pass the verification of the independent server, but informs the server of the status after the client verification to let it issue game items, it would be too scary. This is the IAP built-in Model

Does that mean that the process cannot be made safe at all? No, but this safety guarantee just makes it difficult to modify. Apple officially provides Validating Receipts Locally to perform security verification on receipt-data on the client side, mainly to verify the validity of certificates and signatures. If you don’t want to write code verification yourself, you can also use the receipt-data verification API provided by third-party organizations, the more famous ones are urbanairship and beeflex.

But if we can forge a completely legitimate receipt-data, can we achieve the purpose of deception? Yes, in order to bypass Validating Locally, hackers began to use their own forged receipt-data to embezzle new ideas, so an in-appstore that can forge “legitimate orders” appeared. Therefore, this method of locally strengthening authentication cannot completely avoid IAP attacks.

2.IAP Server Model, server verification

And if we move the validation logic to the server, the process becomes much easier. Because there is no longer any need to worry about receipt-data being forged. However, even if steps 4-7 are performed on the server, some naive logical loopholes will also be generated:

The response content of the verification receipt-data is not verified and recorded, and the products are only released directly according to the Product. In this way, as long as the client keeps submitting receipt-data, according to the normal logic, you need to constantly verify and repeatedly issue products. A safer approach is to:

After receiving receipt-data each time, map the submitted user account and the tracking number in receipt-data and record it. When verifying receipt-data each time, first determine whether it already exists.

As long as such verification is done, the entire payment process becomes clear.
Ensure successful submission and exception handling of receipt-data

It is based on the IAP Server Model, and we know that the mobile phone network is unstable. After the payment is successful, the receipt-data cannot be guaranteed to be submitted to the server. If such a situation occurs, it means that the user has been deducted by the appstore, but has not received the props issued by the server. (This leads to a missed order)

The solution to this problem is to submit the receipt-data to our server on the client side, and let our server send a verification request to the Apple server to verify the validity of the receipt-data bill. Before receiving a reply, the client must Save the receipt-data well, and trigger a request to the server periodically or on a reasonable UI interface, until the client’s receipt billing record is deleted after receiving a reply from the server.

What should I do if the client fails to submit receipt-data? That is, the user was charged a fee and received a consumption receipt from the appstore, but still did not receive the item, so he complained to the customer service.

This situation also occurs in past experience, common disputes between users and operators. The customer service asks the user for the account number and the receipt number of the appstore, and checks whether there is such an order by querying itunes-connect.

If the order exists, you need to contact the research and development party to query the server to see if the order number corresponds to the user name and whether it has been used. The purpose of this check is to prevent malicious users from cheating by using the order number that has already been used (Verified bills can be requested for verification again. For testing purposes, the bills were manually sent to the server for processing and were successfully processed), falsely claiming that they did not receive the product.

Of course, if the order number cannot be found, it means that the order has not been used, and the product can be reissued to the user manually.

A friend asked how to check the specific order through itunes-connect. The order information cannot be directly seen in itunes-connect. You can use the following methods to query

1. You can send the bill to Apple for verification through the bill, and if it is valid, you can manually reissue it
2. Compare with the record bill list of your own server
3. Using third-party trading functions such as TalkingData, billing data will be automatically recorded
   suggestion

In order to ensure the approval of the audit, it is necessary to perform double verification on the client or server, that is, verify with the online transaction verification address first, and if the verification code returned by Apple’s official verification server is 21007, then connect to the sandbox test server again for verification. Just verify.

During app review, Apple IAP review and verification is carried out in a sandbox environment, that is, when Apple reviews an app, it will only purchase it in the sandbox environment, and the purchase certificate it generates can only be connected to Apple’s test verification server. If you do not do double verification, you need to pay special attention to this issue, otherwise it will be rejected.