iOS In-App Purchase (IAP) Development Steps List

A couple of days ago, I worked with the server-side team to complete the development of in-app purchases (IAP). There were many steps involved, so I've summarized the development steps below. Since this is just a list of steps, it doesn't include detailed tutorials. Beginners who need tutorials can refer to the reference links I've included at the end.

Configure Developer.apple.com

Log inDeveloper.apple.comThen proceed with the following steps:

1. Create an App ID without wildcards for the application.
2. Use the App ID to generate and install the corresponding Provisioning Profile file.

Configure iTunes Connect

Log iniTunes ConnectThen proceed with the following steps:

1. Create a new application using this App ID.

2. In this application, create an in-app purchase item, choosing the payment type. Typically, you can choose between two options: Consumable or Non-Consumable. Then, set the price, Product ID, purchase description, and screenshot. Remember the Product ID, as you'll need it later during development. See the image below:

3. Add a test user for Sandbox payments, as shown in the image below. Note that Apple's password requirements for this test user are the same as for the official account: it must be at least 8 characters long and contain both numbers and uppercase and lowercase letters.

4. Fill in the relevant tax, bank, and contact information. See the image below:

Development work (iOS version)

1. Include storekit.framework and #import in your project.

2. Obtain a list of all paid Product IDs. This can be stored locally as a constant or returned by your own server.

3. Create an interface to display all in-app purchases. The prices and descriptions of these in-app purchases can be returned by your own server. However, for offline games or utility apps without a server, you can obtain the information by querying the App Store. During my testing, I found that querying the App Store is very slow, typically taking 2-3 seconds, so I don't recommend doing this; it's better to use your own server.

4. When a user clicks on an IAP item, we first check if the user allows in-app purchases. If not, the following steps are unnecessary. The code is as follows:

if ([SKPaymentQueue canMakePayments]) { // Execute step 5 mentioned below: [self getProductInfo]; } else { NSLog(@'Failed, user has disabled in-app purchases.'); }

5. We first query the App Store using the ProductID of the IAP to obtain the SKPayment instance, and then initiate a purchase operation using the addPayment method of SKPaymentQueue.

// The ProductId below should be a pre-added, existing paid item in iTunes Connect. Otherwise, the query will fail. - (void)getProductInfo { NSSet * set = [NSSet setWithArray:@[@'ProductId']]; SKProductsRequest * request = [[SKProductsRequest alloc] initWithProductIdentifiers:set]; request.delegate = self; [request start]; } // Callback function for the above query - (void)productsRequest:(SKProductsRequest *)request didReceiveResponse:(SKProductsResponse *)response { NSArray *myProduct = response.products; if (myProduct.count == 0) { NSLog(@'Unable to retrieve product information, purchase failed.'); return; } SKPayment * payment = [SKPayment paymentWithProduct:myProduct[0]]; [[SKPaymentQueue defaultQueue] addPayment:payment]; }

6. In the viewDidLoad method, set the purchase page as the purchase observer.

- (void)viewDidLoad { [super viewDidLoad]; // Monitor purchase results [[SKPaymentQueue defaultQueue] addTransactionObserver:self]; } - (void)viewDidUnload { [super viewDidUnload]; [[SKPaymentQueue defaultQueue] removeTransactionObserver:self]; }

7. When the user's purchase action has a result, the following callback function will be triggered, and the appropriate processing can be performed.

- (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray *)transactions { for (SKPaymentTransaction *transaction in transactions) { switch (transaction.transactionState) { case SKPaymentTransactionStatePurchased://Transaction completed NSLog(@'transactionIdentifier = %@', transaction.transactionIdentifier); [self completeTransaction:transaction]; break; case SKPaymentTransactionStateFailed://Transaction failed [self failedTransaction:transaction]; break; case SKPaymentTransactionStateRestored://The item has been purchased [self restoreTransaction:transaction]; break; case SKPaymentTransactionStatePurchasing: //Item is added to the list NSLog(@'Item is added to the list'); break; default: break; } } } - (void)completeTransaction:(SKPaymentTransaction *)transaction { // Your application should implement these two methods. NSString * productIdentifier = `transaction.payment.productIdentifier; NSString * receipt = [transaction.transactionReceipt base64EncodedString]; if ([productIdentifier length] > 0) { // Verify the purchase receipt with your own server } // Remove the transaction from the payment queue. [[SKPaymentQueue defaultQueue] finishTransaction: transaction]; } - (void)failedTransaction:(SKPaymentTransaction *)transaction { if(transaction.error.code != SKErrorPaymentCancelled) { NSLog(@'Purchase failed'); } else { NSLog(@'User canceled transaction'); } [[SKPaymentQueue defaultQueue] finishTransaction: transaction]; } - (void)restoreTransaction:(SKPaymentTransaction *)transaction { // For purchased items, handle the logic to restore the purchase [[SKPaymentQueue defaultQueue] finishTransaction: transaction]; }`

8. Server Verification Credentials (Optional). If the purchase is successful, we need to send the credentials to the server for verification. Considering network issues, the credential sending operation on the iOS client should be persistent, allowing for recovery and retrying if the app exits, crashes, or experiences a network error.

Development work (server-side)

The server-side work is relatively simple, consisting of 4 steps:

1. Receive purchase receipts from iOS devices.
2. Determine if the credential already exists or has been verified, and then store the credential.
3. The credential is sent to Apple's server for verification, and the verification result is returned to the client.
4. Modify the user's corresponding membership permissions if necessary.

To account for network anomalies, server verification should be a recoverable queue, and retry should be performed if the network fails.

The documentation for the verification interface with Apple is inhereIn simple terms, the purchase receipt is Base64 encoded and then POSTed to Apple's verification server. Apple then returns the verification result in JSON format.

The Apple App Store online purchase receipt verification address ishttps://buy.itunes.apple.com/verifyReceipt The verification address for the test is:https://sandbox.itunes.apple.com/verifyReceipt