Regarding iOS In-App Payment (IAP), I have contacted twice during the project development process. This article will introduce the entire development process in detail. I will introduce the IAP product payment and verification process.
Applicable scene
IAP is widely used in mobile games and web games in the iOS system, such as gold coins and gems in some games, using IAP payment. Apple officially stipulates that when APP involves virtual currency transactions, only IAP can be used for payment, otherwise it will be rejected during the APP review process. Many of our daily life applications using WeChat Pay and Alipay can still pass the review because they are used for real-world transactions. In addition, Apple will charge 30% of virtual currency profits.
Type description
- Consumable goods
- Non-consumable goods
- Non-renewable subscription
- Auto-renew subscription
Consumable goods
As the name suggests, commodities that can be consumed, such as gold coins, diamonds, etc. in web games , can be used to purchase currency for virtual items in the app
Non-consumable goods
Commodities that cannot be consumed, such as courses in some educational apps, and race tracks in some racing games, such commodities need to be reviewed and added with a restore purchase button, which is used by the user to delete by mistake or uninstall the app for other reasons Recovery process, otherwise the submission for review will be rejected
Non-renewable subscription
Such goods are similar to consumable goods, such as one-month membership, one-quarter membership, etc. The difference with consumable goods is that such goods need to pass a shared secret key when verifying the certificate
Auto-renew subscription
There are relatively few online introductions of this type of product, and the process of this type of product is slightly different from other products. For applications such as continuous monthly membership in a video app, such products will be automatically deducted when they expire, and the verification logic of the server will be different.
The above is the introduction of the product type, I will introduce this payment process in detail below
Ready to work
Create products in the background of iTunes Connetct and establish a sandbox test account. During the
entire IAP testing phase, only the sandbox test account can be used to test IAP payment, and the credential verification can only be sent to the test verification environment
Since this part is relatively simple, this article does not give a specific introduction, just create it in the iTunes Connetct background and follow the instructions.
It should be noted that if the application is the first IAP development, the personal information (bank card information, tax-related information) in the Apple store must be improved before the related products can be created, and the products need to be reviewed in the next release. After IAP development, you can directly review new products in the background
Payment verification process
First, briefly explain the entire process. Here we take our APP development as an example to illustrate the logic of payment on the client side and verification on the server side to ensure the security of the entire IAP payment
The whole process is roughly
1. The client requests the product order
2. Get the IAP product id
3. IAP product query
4. User payment
5. The client sends the order number + payment voucher to the server
6. The server verifies whether the voucher is valid
7. The result is returned to the client
8. Client business logic processing
Below I will explain in detail about non-renewable subscriptions and auto-renewable subscriptions. Consumable products and non-renewable subscriptions are similar and relatively simple ==
The non-renewable subscription payment process (take one-month membership as an example)
first place an order with the server, carry the product id created in the background, place the order with your own server, and get the order number in the successful callback and store it
/**
下vip订单
@param params 参数 @"item_id" : @(itemID),
@param success 成功回调
@param fail 失败回调
*/
- (void)makeVipOrderWithParams:(NSDictionary *)params
success:(RequestOrderSuccess)success
fail:(RequestOrderfailBlock)fail;
After the order is successfully placed, the product will be paid. There are many demos on the network during the payment process, and no explanation will be given. For details, please refer to the tool class IAPHelper on github
/**
购买对应商品identifier后的回调
@param identifier 商品identifier
@param completion 回调
*/
- (void)payProductsWithIdentifier:(NSString *)identifier
completion:(IAPbuyProductCompleteResponseBlock)completion;
When the user pays successfully, the certificate is obtained in the callback, and the server is requested with the certificate order number and user uid as parameters, and the server verifies whether the certificate is paid to the Apple server
/**
查询vipIAP支付结果
@param orderID 订单ID
@param receipt 凭证
@param uid 用户uid
@param success 成功回调
@param fail 失败回调
*/
- (void)requestIAPResultWithOrderID:(long long)orderID
receipt:(NSString *)receipt
uid:(NSString *)uid
success:(RequestQuerySuccess)success
fail:(RequestQueryFail)fail;
Here, the server authentication credentials, because the non-renewal subscription payments, need to bring in the above-shared key and certificate for authentication, verification results are returned Apple details of the order, the server returns to service processing according to information
the client After receiving the verification result, refresh the interface to complete the entire process
Automatic renewal subscription payment process (continuous monthly subscription)
The payment process is the same as above. The different special processing is that the server will store the user's certificate after the verification is successful. When the user's membership expires at this stage, the user will query the certificate again. When the validity period of the query certificate changes, according to the specific request result, Extend the membership for one month for the user, otherwise, cancel the membership after expiration
Lost order handling
Since the IAP server cannot guarantee the quality, or when there is a problem with the verification of the credentials on the own server, there may be a loss of the order (the user has successfully paid the payment, but the voucher cannot be successfully verified with the own server). In this case, we can handle this situation
After the user places an order successfully, save the order & uid & certificate
/**
存储 订单&uid&凭证
@param orderID 订单
@param uid 用户uid
@param receipt 凭证
@param saveKey 储存key
*/
- (void)saveOrderReceiptWithOrderID:(long long)orderID
uid:(NSString *)uid
receipt:(NSString *)receipt
saveKey:(NSString *)saveKey;
After the user successfully authenticates to the server or fails due to non-network reasons, delete this record,
/**
删除 订单&凭证
@param orderID 订单
@param receipt 凭证
@param saveKey 储存key
*/
- (void)removeOrderReceiptWithOrderID:(long long)orderID
receipt:(NSString *)receipt
saveKey:(NSString *)saveKey;
In this way, if the order is lost due to network problems or server problems, we can verify the order again the next time the user starts the APP, and repeat the above process
/**
核对支付成功但是验证失败的订单
*/
- (void)checkLocalLostVipOrder;
Fake order processing
IAP payment will inevitably result in the verification of some forged certificates. In this regard, the server must be very careful about the verification of the certificate. Our APP has received verification of forged certificates. You can refer to the verification:
1. Check the itemID after the certificate is verified
2. Check whether the certificate is a certificate in the formal environment
3. Check the validity time of the certificate
4. For the processing of jailbroken users, when I paid for consumables before, there are some IAP plug-ins for the jailbroken users Yes, we choose to directly pay for jailbroken users through WeChat. As the judgment logic increases later, IAP payment is also enabled for jailbroken users
Review needs
During the IAP audit, you need to provide a sandbox test account and an APP test account. During the review process, our entire process has been switched to a formal environment, but the reviewer still uses test credentials to verify. Our server needs to be in the review phase. The credentials of this uid still go to the test verification interface to verify, otherwise it will be rejected