Since last year I has joined a company that is making an app that allow to purchase in app credits that can spend on their services. As I joined as backend developer responsible on wallet related features, I had the chance to work on integrations of In-App purchases for Apple, Google, Huawei, and Alipay for China.
Diagram below shows that our application has to implements 4 In-App purchases for different platforms. IOS app only required to upload to Apple Store, while Android required to deploy in few app store, which is Google Play, Huawei App Gallery, and few China’s app store.
On user side, they will do the following steps to make purchases.
- Open the products list which is fetched and shown by app.
- Choose product to buy, check the details and press the “Buy” button.
- Select payment channel (bank cards, mobile payment or other payment type depends on platform)
- Click “Make Payment” button to complete the payment.
- Redirected back to mobile app.
Purchase flow is same for users in any platforms, but things that happening inside backend service was another story and each was handled separately.
There are few type of In-App Purchases in Google. It is In-App Products and Subscriptions, while In-App Products has Consumable and Non-Consumable products. Consumable In-App products is the types that will be used.
Here are some important facts from Google’s IAP documents.
- Android app can make purchases directly to Google API server, consumed product and acknowledge the purchase to verify the transaction.
- Transactions that is not acknowledged will be refund to users in 3 days.
- When transaction is not consumed, user will not allowed to make purchase on the same product again.
After gathering all API specifications, we design a purchases flow and documents on this flow chart.
In this flow chart, backend services will provide 2 endpoints for mobile, the first endpoint was called after user made payments; another one is call after product is consumed and purchases has acknowledged.
The first endpoint is simply to store the purchase information in server, second endpoint verify purchases information with Google Api and grant product to user.
After this implementation up and running in production for a week, few transactions has detected that is completed but backend was not getting the update of confirm transaction. Therefore, we investigate the cases and we found that the app might have network failure or other unexpected failure after transaction has acknowledged.
Discussion to deal with this failure was made between us, and we had decided to make acknowledge from server side. It can effectively prevent the unexpected failure that can cause purchase successful yet user doesn’t receive the product.
Apple
Reference: https://developer.apple.com/documentation/storekit/in-app_purchase
Apple In-App purchases types is same as Google and we are using consumable In-App product. The documents shows that Apple provide only 1 API for backend to verify receipt and also use only 1 function to make the payments on mobile application.
After we learned Apple API specification, we design the flow below. Backend provide only one endpoints to mobile app and it will be use after a successful purchase. Mobile app will get the receipt information from purchase and submit to backend service. In this endpoint, backend will use the verify API from Apple server using the receipt information.
Surprisingly, App Store admin panel don’t provide transactions report. Which means it don’t allowed us to matching the transaction id manually to our user’s receipt. This is usually the fallback plan that nothing work well in any API integrations.
Besides that, we found a critical issue in the flow and couldn’t be fixed. There was some case that mobile fail to acknowledge backend after successful payment on AppStore.
We can’t make a good way to deals with this issue, while user request credits refund from AppStore got rejected by Apple. 3 months later, we discover this news. Apple is now allowed server to server notification. Without a second thought, I create an endpoint to handle refund notification and release to production. Although couldn’t solve the issue but it allow user to get credits refund from AppStore.
Huawei
The In-App purchases flow is exactly the same as Google. Yet there is an obvious different I found on development, that is no Huawei SDK for PHP. Although it required to code more, its documents do a really good helps and it has recommend the right way of implementation.
We made the flow chart below, it is same as Google’s flow and the purchases will be verify and acknowledge from backend which was recommended in their document.
Although the integrations is pretty easy to understand, but the charges is really complicated compared to any other platform. Google/Apple charges only 30% of product’s price, while Huawei add an extra charge based on user’s countries and payment methods (Huawei Developer Documents).
This is a payment that is to serve our users who live in China and using Android app that installed from Chinese App stores. It was really tough to get through levels of verifications to get our Alipay business account approved due to China government has strict requirement on their internet contents and payment.
After few attempt, we decided to integrate the payment through a Chinese payment merchant to get their advice for the integrations. Although they provide good service in technical support, it still took me lots of effort to implement the integrations as the their SDK is so buggy. It has gave me some “surprise” that made me had to work through the night to fix it.
Besides, it using a technology that we seldom use in web applications which is MQTT protocol. Our application’s backend is required to establish a connection to Merchant server in MQTT protocol and listening updates on all our transactions.
Among these In-App purchases, Apple offer the solution that is easiest to integrate but it couldn’t let us handle exception case. Apple don’t make their admin panel for us to see or download our transaction reports and the flow don’t care if our application’s backend was acknowledged.
Google and Huawei had the similar flow and it is a little bit more thing to do compare to Apple. In my opinion, this is already a complete solution and it is good for long run; as it is able to handle any use case.
China payment is the most difficult to integrate among these In-App purchase, but it might worth to do it. The solution they offer actually does better than other providers as it implementation of technique with the use of some advance technologies that secure the payment process and improve the efficiency of communication between server.
