FGIAPService supports Cocopods, a basic component that is easy to use and efficient.

background

Unlike remote verification by wechat/Alipay payment server, the transaction verification after IAP deduction is done by App driven App server. However, the network environment of mobile devices is far more complex than that of servers. After successful deduction, subsequent bill issuance and App upload bill will face severe tests (network abnormalities, App server abnormalities, Apple server abnormalities, etc.).

There are already tripartite libraries for IAP on the market, such as RMStore, IAPHelper, etc., that are relatively mature, but why write another solution?

  1. You want to be able to couple certain order services so that you can access projects faster and more easily
  2. The transaction verification after IAP deduction is completed by App driven App server, and many abnormal processes will have the risk of missing orders if they are not handled correctly
  3. Apple recommends checking tickets through the server
  4. Continuous maintenance

The basic principle of

There are many tutorials on iTunes to configure and create products, but I will not describe them. Here is a brief description of the server ticket verification process

The bill process is divided into two types: one is to purchase and verify directly using Apple’s server, and the other is to verify by assuming a server. Because it is very slow to verify the connection between the Domestic network and Apple server, and in order to prevent hackers from forging the purchase certificate, the general practice is to set up their own server for verification. Here is the server validation process

  • The user enters the page of purchasing virtual goods, and the App obtains the product list from the background server and displays it to the user
  • When a user clicks buy to buy a virtual item, the APP sends the productionIdentifier of the virtual item to Apple server and its own server to generate SKProduct and tradeNo respectively
  • The user clicks ok to buy the item and sends the purchase request to An Apple server
  • After the Apple server completes the purchase, it returns a completed ticket information to the user and sends it to the background server for verification
  • The backend server sends this credential to Apple for validation, and Apple returns a field to the backend server indicating whether the credential is valid
  • The background server sends the verification result to the APP, and the APP processes the verification result accordingly

FGIAPService technology implementation

There are too many potholes in IAP payments, here are some common issues collected

Channeling order (Order mapping)

Order mapping refers to the mapping of business orders and IAP orders, essentially binding the business order number tradeNo to Apple’s Transaction Order (Receipt)

  • After the IAP payment is initiated, we give Apple an SKPayment object and finally listen on an SKPaymentTransaction object (with SKPayment property). We can implement order mapping by using the applicationUsername field of SKPayment;
  • The receipt message returned by Apple Pay successfully contains the dictionary information related to the item, which can be bound by submitting tradeNo and Receipt to the server
  • Open the server verification interface through the ID protocol
  • Switch account on APP: Charge money according to account and order during verification

Leakage of single

For consumable and non-consumable goods, transactions that do not finish appear in the updatedTransactions function (the subscription type appears with or without Finish). This is common in functions that observe the payment queue, give finishtransactions whatever state they are in, and then build their own wheels for local storage and retransmission. Often after finishTransaction, there is a problem with the self-made wheel, resulting in order loss.

  • Construct transaction verification queue; After the persistence of each transaction data is successful, order verification is attempted, which consists of two steps: uploading the bill and querying the order status; If both steps are completed, the order is completed and the finishTransaction operation is executed.
  • Failed polling: If apple pay succeeds but the server fails to verify the order, a timer will be started to poll the order
  • APP abnormal flash backoff: Once the APP is started, it will process an uncompleted transaction order by observing the payment queue
  • Delete the APP: Once the APP is started, it processes pending transaction orders by observing the payment queue

Bill problem

  • After iOS 7 (almost all apps start from iOS 9), receipt data is obtained from [[NSBundle mainBundle] appStoreReceiptURL]]. If the App uploads the ticket information, the data will be uploaded together;
  • After iOS 7, the receipt information in [[NSBundle mainBundle] appStoreReceiptURL] is a receipt list (in_app field) with “automatic repair”. If a payment is not completed correctly, the receipt information in [[NSBundle mainBundle] appStoreReceiptURL]] is a receipt list with “automatic repair”. The subsequent recovery was unsuccessful; When he generates the next successful payment, [[NSBundle mainBundle] appStoreReceiptURL]] will contain the receipt of these payments.
  • Ticket verification: The ticket verification is handed over to the server, and the sandbox environment is determined by the request environment

Abnormal data loss

  • ApplicationUsername lost: Store tradeNo with applicationUsername and there is a certain chance that it will be retrieved to nil. To ensure that tradeNo is not lost, tradeNo and productIdentifier will be persisted to the keychain. Persisting transaction data to keychain has two benefits:
    1. Data stored in the keychain is encrypted for security.
    2. Even if the App is uninstalled, data in the keychain is not deleted.
  • Note loss: If the payment transaction is successfully monitored, but the data obtained from [[NSBundle mainBundle] appStoreReceiptURL]] is empty, you can mark it and obtain the bill data again through SKReceiptRefreshRequest.
  • TransactionIdentifier missing: The support process is completed by order mapping and does not need to consider the transactionIdentifier

IAP surrounding Construction

Perfect the burial site

  • In the payment process, the critical path burying point, including but not limited to: persistent transaction data operation, bill uploading operation, query operation, end check operation, etc.
  • Monitor abnormal conditions, including but not limited to: persistent transaction data failure, upload failure, applicationUsername get order number is empty, query failure, etc.
  • During development, display as much debug log information as possible.

Responding to user feedback

  • No matter how good the solution is, it cannot handle all IAP problems. Establish a user feedback response mechanism and respond to user feedback in a timely manner.
  • TradeNO/orders that cannot be obtained will not finish normally, so manual help is needed to help users solve the problem before closing.
  • Reserved ErrorCode: 11000007 to delete a local expired order

summary

Since in-app purchase is directly related to the company’s profits, we need to be more careful. Therefore, in the scheme design stage, we investigated many articles and materials, including tripartite libraries: RMStore and IAPHelper. Analyze the advantages and disadvantages of its design.

I reviewed the development and debugging process, understood the process and implementation mechanism of the whole payment link of IAP, and then realized an IAPService by myself. I also spent a lot of time in the development process to solve the specific implementation section mentioned in the article.

In general, got a good exercise, worthy of ~ need friends, as soon as possible to use it: project address

Refer to the article

Apple Iaps 2 and 3 things about Apple’s in-app Purchase development are some of the bugs and failed purchases