"IAP Payment II" in app purchase local purchase and server purchase two modes of purchase

Developers in the game through the IAP to pay the players, the actual development of problems encountered:

Communication between the 1.StoreKit and AppStore

At first there are concerns about the game inside and AppStore communication between the intermediate links, in fact, this completely do not consider, the communication between Storekit and AppStore is completely apple internal processing, there is no problem, we need to concern is to return to our payment results (purchase success, failure, Cancel ...) Processing of such links

The store kit represents the communication between the app and the App Store. The program will receive information from the App store about the products you want to provide (the site is configured in the background) and display them for the user to purchase.

When a user needs to purchase a product, the program calls Storekit to process the purchase information. This is the basic store kit model:

2. Local Purchase and server purchase

Delivery method

There are two types of purchase delivery mechanisms for Apple: the built-in type (built-in model) and the server model, the popular point is local mode and server mode . Regardless of which model you use, you need to maintain a product list (a list of products that are configured from the background of the site) and ensure that the product is delivered successfully when the user buys it.

(i) built-in Purchase (local/standalone mode purchase)

Products that need to be delivered are already configured within the program (stand-alone mode) Eg.om.mtt.happbird.gold1 corresponds to the purchase of a store coin item 1.

Note: In APP purchase does not provide the ability to purchase patches. If you need to change the bundle for your app, you must submit a new app version to the App Store.

Popular point is to set up the bundle ID and other information, do not blindly change ...

The single-machine mode purchase process is as follows:

Shows the process for delivering built-in products.

1. The program obtains a list of product identifiers through the plist file stored by the bundle. (Download the product list from the background of Apple website, this must have)

2. The program sends a request to the App Store to get information about the product.

3. The APP store returns product information.

4. The program displays the returned product information to the user (app's store interface)

5. The user selects a product

6. Program sends payment request to App Store

7. The APP store processes payment requests and returns transaction completion information.

8. The app obtains information and provides content to the user.

The entire process is secure, both Storekit and AppStore communication, and all you need to do is set and callback to accept the result.

The above procedure is OK, if from the security (game more robust) point of view, after the process "8", there should be an Apple server to verify the purchase of the bill receipt process, whether it is a stand-alone purchase or server authentication purchase.

(ii) Server type

Popular Point Introduction: Is the single-machine process after the successful purchase, the game client will get the purchase result: The purchase result and the bill receipt, if you are a stand-alone mode does not consider the security situation, you can directly to the players to issue props. Now that hackers are rampant, they can simulate the results of Apple's feedback. What we need to do is:

Purchase success = AppStore Feedback results and receipt = Send to server (our own server non-Apple server) + + server sends bill to Apple server = Apple server receives and verifies that the + server receives billing test results Server processing results (eg. plus money ...) = Feedback client Processing

The security of doing so is: not what your client said is what, until I verify that you are really fake.

Purchase process for server type

1. The program sends a request to the server to obtain a list of products.

2. The server returns a list containing the product identifiers.

3. The program sends a request to the App Store to get information about the product.

4. The APP store returns product information.

5. The program displays the returned product information to the user (app's store interface)

6. The user selects a product

7. Program sends payment request to App Store

8. The APP store processes payment requests and returns transaction completion information.

9. The program obtains data from the information and sends it to the server.

10. The server records the data, and carries on the examination (our) checks.

11. The server sends the data to the App Store to verify the validity of the transaction.

The APP store parses the received data and returns the data and identifies whether it is valid.

13. The server reads the returned data to determine what the user has purchased.

14. The server passes the purchased content to the program.

3. Information configuration and/or acquisition of in-game props

There is, possible methods to retrieve, the products to display to the user:1), hard-code the products into the app or 2) Get a list of products from a server. The second option is highly recommended as it allows your to modify products and pricing without have to update the IOS a Pp. The first option is appropriate if you are only having products that unlock functionality locally within the app and don ' t n Eed to be updated often.

As above, the configuration of the props information in two ways, one is in-game direct configuration, the second is to get props from the Apple server information, is highly recommended, because you can modify the information from the Apple website background, without the need to update the game version (the audit process is very time-consuming). Regardless of which model you use, you need to maintain a product list (a list of products that are configured from the background of the site) and need to embed Storekit.framework

But this is not dead and depends on the situation of your game:

1. The game does not need to change the item information frequently. The inside of the game is properly arranged.

2. The game needs to change the item information frequently. Suggest getting information on the site and updating the display within the game.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

"IAP Payment II" in app purchase local purchase and server purchase two modes of purchase