4.1 Apple IAP Ecosystem - Complete Solution to Data Structure and Implementation

In the previous chapter “4. In-App Purchase (IAP) - Understanding the Overall IAP Ecosystem”, we went through the four links of “can buy, can verify, can restore, and can audit”, which was more about building a conceptual foundation. When it comes to the Apple chapter, I want to take a closer look: when you actually implement Apple IAP, what roles will you encounter, what processes will you run, what pitfalls will you step on, and how will you tie those seemingly repetitive IDs into a clear net.

I strongly recommend everyone to watch this video. You can understand the overall ecology and various IDs to a great extent. (Apple Developer)

How to run Apple IAP data

If you don’t clearly understand the role of the entire ecosystem, there is no point in just memorizing a bunch of IDs. I will first split Apple IAP into three rings:

1. Client & StoreKit: Responsible for displaying products, triggering transactions, and uploading tickets;

2. Apple Services: App Store is responsible for payment and generating invoices; while App Store Server API + Notifications is used to notify and check transaction status; (Apple Developer)

3. Our own server: Verify bills, issue/recover rights, audit and reconcile.

Recommended entrance: StoreKit 2 official page, including overview and resource collection. (Apple Developer)

The order of data flow in these three rings will almost never change: the client initiates a purchase -> the App Store generates a transaction and writes it to the server -> StoreKit uses the ticket to pass the transaction back to us -> we call the Server API or wait for Notifications to obtain the status -> the data is dropped into the database and rights are issued. After understanding this sequence, look at the IDs of transactionId and webOrderLineItemId and you will know which link they belong to. (Apple Developer)

Product preparation and definition

In fact, the implementation of Apple IAP does not start with writing code, but starts with basic preparations such as “whether products can be created, whether settlement can be correct, and whether you can log in in the test environment.”

Roles and Permissions

The Apple Developer Program and App Store Connect each have a role system. IAP involves several key roles: Account Holder (only he can sign the agreement and create advanced features), App Manager (configure the App), Developer (upload the build), Marketing (view sales data). If there is no cooperation from the Account Holder in your team, the “automatic renewal agreement” related to the subscription cannot be signed at all.

Product design documents

Apple product creation is completed in App Store Connect. On the surface it looks like filling out a form, but in reality there are a bunch of constraints:

* Reference Name can be written casually, but it will appear in the report;

* Product ID can never be modified or deleted after it is created, and can only be removed from the shelves, so the name must leave room for expansion;

* Cleared for Sale will be checked by default. If it is accidentally removed, the client will not be able to see the product;

* Subscription products need to configure cycle, price, trial period, promotional offers, and subscription groups.

I actually treat product design the same as architectural design, and wrote a special SKU Sheet (because there are too many subscriptions and products in my product), which contains productId, display name, currency, price level, whether it is family sharing, which subscription group it belongs to, and whether discount codes are allowed. Once someone wants to make changes after going online, they must first change the SKU Sheet and then go to Connect to ensure that the information is synchronized. (Picture and text reference: App Store Connect “In-App Purchase Information/Manage Subscriptions/Win-back offers” and other help pages.) (Apple Developer)

How to split subscription groups and cross-subscription groups

A subscription group can be understood as an “equity line” that Apple maintains for you. All subscriptions in the group are mutually exclusive and share trial/discount status. It is the basic unit for realizing the automatic renewal strategy.

Subscription Group

Apple requires that each auto-renewing subscription must belong to a subscription group, and users can only hold one subscription in the same group at any time. The responsibilities of the group are:

* Definitions are mutually exclusive: For example, “monthly” and “annual” are the same equity line, and only one of them can be chosen;

* Constrained upgrade/downgrade rules: StoreKit relies on subscription groups to determine scenarios such as price difference payment and proportional refund;

* Provide a unique subscriptionGroupIdentifier to help the server model, reconcile and identify which equity line refund/renewal callbacks come from;

• Associated with the validity conditions of Intro Offer / Promo Offer / Win-back Offer - because these