=
Still have to check your own program.
=
Copyright statement: welcome to reprint, please keep the original link .
The phenomenon of swiping orders for Apple recharge is very common in the game industry, and many teams go to great lengths to find loopholes to make illegal profits. Although the developers who encountered the fraudulent bills see beautiful running numbers on the books, Apple will not split the problem bills, resulting in bad debts. It is rumored that some games have a bad debt rate of more than 80% in severe cases. There are five common methods:
- Crack IAP to bypass Apple's chargeback
- Reuse receipt-data
- Use credit card black card
- Take advantage of foreign currency card discounts to earn the difference
- Utilize Apple's "36 Technology" that does not implement verification rules for small purchases
Among them, the first two are program problems of the developers themselves, which can be solved by improving the verification process in the code, and the latter three are exploiting some loopholes in Apple's recharge policy. However, these loopholes will not cause losses to Apple, so Apple has no idea of modifying this. To solve the problem, developers still rely on their ingenuity and data analysis to formulate proper defense strategies.
The following describes the principles and preventive methods of the five methods one by one.
1 Crack IAP to bypass Apple's chargeback
Common in stand-alone games, first look at the timing diagram of Apple recharge:
When the client requests a purchase, the AppStore processes the deduction. If the data named receipt-data is successfully returned to the client, the safe processing flow is to send this data to the server, and the server initiates a request to call the Apple verification interface for verification. Validity of receipt-data.
Some games, which are common in stand-alone games, directly initiate a call to the Apple verification interface on the client side, and even skip steps 3 to 7 to directly process the delivery. Then illegal users can use plug-ins, such as iAP Cracker, to simulate a successful deduction after the client requests a purchase. The client's data is insecure, and even if the client verifies the receipt-data, the result may be tampered with.
The way to prevent this kind of fraud is to strictly implement steps 3 to 7, and verify the validity of receipt-data through the server side.
2 Reuse receipt-data
This problem occurs because although the validity of the receipt-data has been checked in a safe manner, the uniqueness of the receipt-data has not been checked. The data format returned by the Apple Inspection API is as follows:
The data is in json format, where the status value is 0, indicating that the receipt is valid, but Apple is only responsible for true and false, not for checking whether it has been used. The same valid receipt, no matter how many times and how long it takes to go to the Apple interface for verification, will return success. If only the "status": 0 is checked and the goods are shipped, the illegal user can recharge the money first, intercept the receipt-data, and then use it many times to deceive the server-side verification in the purchase.
The method of prevention is to further parse out the transaction_id in the data and store it in the database after determining that the status value is 0. Before each shipment, check whether the current transaction_id already exists in the database, and reject the shipment if it already exists.
There is another situation that needs to be noted. Some games have the act of creating an order one step before purchasing, recording the purchased goods, time, etc. on the server side, and the goods are shipped according to the goods in the order record, so it is necessary to compare the information returned by Apple. Whether the product_id is consistent with the record value in the order table.
3 Using a credit card black card
This is the most common method of swiping bills. It means that users use invalid credit cards to make purchases in the AppStore. Since the credit card has been frozen in the bank, the bank will not settle the payment to Apple, and Apple will naturally not share it with developers.
The usual form is that the user goes to the transaction website to find an agent, and the merchant who charges the account uses the AppleID bound with the black card to recharge the user's account, and charges an amount far lower than the normal price. There are also rechargeable merchants who call a large number of non-game users to take orders, recharge the designated account and then apply for a refund, and give these participants certain rebates to achieve "win-win".
In this case, in addition to relying on Apple's stricter review of credit card information, developers can also minimize losses by monitoring and analyzing data. For the most common form of charging, we can speculate:
a. When the user recharges, it is not on his usual device, but is operated by the merchant on his own device
b. The merchant's recharge device may recharge multiple accounts
The user's commonly used devices can be analyzed through the user's daily game records. If the user switches to a less commonly used device only when recharging, it can be judged as a suspicious user. If some devices only appear in the recharge records but are not commonly used by any user, users who use these devices to recharge can also be judged as suspicious users.
Suspicious users can be further analyzed, and after determination, deduction of illegal gains, account closure, etc. can be performed.
4 Take advantage of foreign currency card discounts to earn the difference
This is a method of brushing orders that takes time. In some emerging markets, such as Mexico, Turkey, etc., Apple has special discounts. Use these currencies to recharge, and the difference after the discount is the profit of the transaction. Another case is to take advantage of changes in exchange rates, such as the famous South African dollar incident.
It is also very simple to prevent this method. The client obtains the currency type used by the user for payment and sends it to the server for verification, and establishes a currency whitelist on the server side. Only RMB or the currency of stable countries and regions is allowed to be used for payment.
5 Using Apple's "36 Technology" that does not make verification rules for small purchases
This is a more technical method, using Apple's rule of not verifying small-amount consumption of credit cards, and using automatically registered virtual credit cards to complete the card binding. After the user initiates the purchase, Apple will return the success information to the client without confirming the deduction, and when the credit card is debited after that, the money will not be deducted.
From the developer's point of view, the order is real and valid, and the receipt-data can also be verified by Apple's servers, but Apple will not split these bills in the end.
Compared with the traditional black card, this method realizes automatic processing, the efficiency of billing is very high, and the loss to developers is greater. Especially in games with trading functions, the scavengers recharge a lot, and then exchange them for currency or props in the game to sell to ordinary players at a low price.
For this method, what developers can do at present is to monitor the abnormal recharge behavior of users, and restrict users who frequently recharge in small amounts. In mobile games, common small-value products are 6 yuan and 30 yuan products. You can also directly limit the number of daily purchases of these small-value products per user to reduce losses as much as possible.
=
=
=