4. In-app purchase (IAP) - understanding of the overall IAP ecosystem

IAP is a key part of the mobile business closed loop. A truly stable IAP system is not only capable of being purchased, but also capable of being verified, restored, audited, and capable of dealing with boundaries.

There will be three chapters. The first chapter talks about the most basic concept of IAP, the second chapter talks about the payment/subscription system of Apple Play, and the third chapter talks about the payment/subscription system of Google Play.

My thoughts on these three chapters are as follows: the back-end implementation of business will be very different, so it is not within the scope of this article. I will try to focus on the ecosystem. After understanding the entire ecosystem, the back-end is just pure code logic issues such as which table to insert, which task the timer processes, and how to write idempotent payments.

When I was actually developing this content, the most time-consuming part was actually understanding the two major ecosystems. This part of the debugging was also the most painful. After running through the ecosystem, the code implementation was actually not complicated.

Foundations of IAP

I want to answer three questions first: who is buying, what is being bought, and how the money is recognized. As long as these three points are clear enough, the following chapters on Apple and Google will not look like a black box.

When doing IAP, many of us will focus on the purchase entrance of the client, but the real subject is actually the triangular relationship: users, platform stores, and our servers. The client is just a tool for users to submit their intent. The store is responsible for generating transaction vouchers, and the server needs to use the vouchers to interpret and redeem rights and interests. If any corner's understanding is not deep enough, it will leave a hole after the release.

The process is to get the receipt first, then ask the store, then let the server keep accounts, and finally authorize the user. "Ask the store" here means that the server takes the ticket and immediately requests the store interface for verification. The client immediately POSTs the ticket to the server in the callback of purchaseSuccess, and then waits for the server to return the verification result.

To make this triangle relationship run smoothly, permission management and status synchronization must also be planned in advance. It is better to have an "order state machine" on the server side instead of several fields scattered in various tables.

"Can buy" is just the entrance ticket

IAP seems to be a simple process of button