HUAWEI In-App Purchases (IAP) implements convenient in-app purchasing via either the service's SDK or its server.
Features and integration details of IAP are well illustrated in its official documents. I've used the service extensively for my apps and kept track of its issues (both from myself and other developers). Following on from my previous article that looked at the sandbox testing issue, this article will present FAQs related to other IAP aspects.
Question 1: The callback request of IAP is empty, containing no valid user information. Why?
Question details:
I integrated my app with HMS Core SDK 6.4.0.301 and IAP SDK 4.0. Users paid for a yearly subscription in the app, but the backend of my app didn't automatically deliver the subscription to users. I went to the order report in AppGallery Connect to redeliver the subscription to users, but the callback result was invalid.
To troubleshoot this issue, I used the test API. In the printed callback request of IAP, I discovered that the request body was an empty string that contained no valid user information. So I checked the official IAP document, which says that an app using IAP SDK 4.0 will not receive the payment success callback, so I'm not sure whether it is normal that my app received an empty callback.
Also, the subscription callback API of the IAP server would return 200 even upon an exception. The reason, I assume, was that the IAP server believed that my app had delivered the subscription to users. In this case, can product redelivery be triggered after the app is restarted?
Answer:
The official FAQs section for IAP illustrates what will happen after the redelivery button in the AppGallery Connect order report is clicked.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Normally, there will be no callback upon payment success. However, a callback containing an empty request body is actually not an issue, which can be ignored.
The redelivery process of the IAP SDK applies only to consumables, which needs to be triggered in the app integrated with the SDK in some specified scenarios, such as app startup. When an exception occurs during the process, an error code (like -1, 60051, or 1) will be returned, which you need to deal with according to the error description. More details can be found here.
As for subscriptions, notifications of key events are used. Click here for more details.
In no scenario would the IAP server send 200 upon an exception to your app server because the IAP server believes that your app has delivered the subscription to users. If you are not sure why your app server receives 200, you can submit a ticket online with the order number corresponding to the subscription in question for the technical support of IAP to look into.
Question 2: I submitted settlement sheets in September 2022, and the sheets have been stuck in the In payment state since then. However, the corresponding earnings have not been sent to my bank account. Why?
Answer:
The official Settlement document says that after a settlement sheet is submitted, the sheet will enter the In payment state. To receive the earnings, you may need to issue an invoice, according to where your app is released.
Specifically speaking, you are not required to issue an invoice if your products are distributed in countries or regions outside the Chinese mainland, and you have signed an online agreement with Huawei. According to Exhibit C of the HUAWEI Developers Merchant Service Agreement, Huawei will perform self-billing. To view and download invoices issued by Huawei, sign in to the console of HUAWEI Developers and go to My accounts > Credited. Find your settlement sheet and click Invoice.
If your app is released in the Chinese mainland, issue an invoice according to the official instructions.
Multiple settlements can be combined for invoicing in a single application. Such settlement sheets must have the same contract, service type, currency, signing entity, and prepayment term. It's also worth noting that the invoice amount must be the same as the amount sum of the combined settlement sheets.
For details about how to perform invoicing and other settlement-related instructions, go to the Self-service Settlement Guide.
Question 3: The official IAP document noted that it would gradually end support for the old domain names of AppGallery sites, TLS of earlier versions, and cipher suites. Are there any detailed instructions on how to replace the old domain names, TLS versions, or cipher suites with new ones?
Question details:
To ensure higher security and reliability for apps, IAP has changed its support for the domain names of AppGallery sites, TLS versions, and cipher suites. Specifically speaking, from April 2023, IAP will no longer support TLS earlier than 1.2 version or cipher suites that are not specified. The support for old domain names of AppGallery sites will be canceled in the near future.
Answer:
There is no guide document illustrating how to replace the old TLS versions or cipher suites, but the official IAP demo can serve as a reference.
The sample code of the API for verifying the purchase token of the order service is used as an example here, to show how to replace the old domain name. For example, for an app released to AppGallery in the China site, replace
https://orders-at-dre.iap.dbankcloud.com
with
https://orders-drcn.iap.cloud.huawei.com.cn
, which is the domain name of this site.
Click here for more information.
Question 4: I noticed that there is an expirationDate field in the subscription purchase data of users, which is returned by IAP. Is the time indicated by this field the same as the time when IAP bills the user account for renewing a subscription near the end of the current billing cycle?
Question details:
A user purchased a yearly subscription on December 5, 2021, and IAP returned the expirationDate string, which is a timestamp. On December 4, 2022, IAP automatically billed the user account for subscription renewal. However, the time indicated by the timestamp is December 8, 2022. My question is: Will IAP bill a user in advance for subscription renewal? If not, does this mean that the expirationDate time is not the same as the time of billing for subscription renewal? Which field should I refer to if I need to know the billing time for subscription renewal?
Answer:
In short, the time indicated by the expirationDate field is not the same as the billing time for subscription renewal.
Below is the official description of the expirationDate field in the InAppPurchaseData class.
In other words, this field indicates the time when a subscription expires.
According to the billing rule of IAP for a subscription, IAP tries to bill a user 24 hours before a subscription renewal. Therefore, it is normal that IAP billed the user account on December 4, 2022, which is within 24 hours before the current billing cycle ended (December 5, 2022). If billing fails, IAP will repeatedly attempt to bill the user within a specific duration. Once the maximum number of failed attempts has been reached, IAP will cease billing.
On top of this, the IAP server does not return the billing time for subscription renewal or provide any accurate billing time. Instead, the server provides the subscription renewal time that may be slightly earlier than the billing time.
If you find the difference between the subscription renewal time and the time indicated by expirationDate is too big, you can submit a ticket online with the subscription order number or subscription ID for troubleshooting.
References
Home page of HUAWEI IAP
Development Guide of HUAWEI IAP
Related
HUAWEI In-App Purchases (IAP) provides a wide range of functions related to in-app product purchases and subscriptions, while also providing easy-to-view summaries related to in-app sales, purchases, and subscription through multi-faceted data analysis. The service enables you to view sales or revenue for products, such as VIP memberships or game equipment, over specific periods of time by clicking Console on HUAWEI Developers. This data comes straight from the local service area, and is updated on a daily basis.
How can you view the data you need?
Ø Overview Page
Sign in to AppGallery Connect and find Analytics. Click Operation Analysis, located below Analytics, and choose the app for which you wish to view detailed data. On the Overview page under Financial reports, you can view the following data by currency (CNY, USD, and EUR).
l The total revenue, Average Revenue Per Paying User (ARPPU) over the past 30 days, and average value of each deal for an app.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
l The number of different types of buyers over the last day, last seven days, and last 30 days, in the Buyers table. Buyers include both new buyers and returning buyers. New buyers are those who make their initial purchases during the specified period. Returning buyers are those who had previously made a purchase in your app, and have made a purchase once again during the specified period. Total buyers refer to all the buyers who make purchases during the specified period.
l The revenue data for the last day, last 7 days, and last 30 days, in the Revenue table.
Revenue sources include the following items:
1. Paid app downloads: Revenue generated from paid app downloads.
2. In-app purchases: Revenue generated from the purchase of in-app products.
3. Subscriptions: Revenue generated from ongoing subscriptions.
Total revenue refers to the total sum of these three revenue sources.
Ø Revenue page
Above the Revenue (by product) table, you can opt to view the data by specific country or region (multiple choices supported), currency (CNY, USD, and, EUR), and time period (last day, last seven days, last 30 days, and all time).
After setting these filters, you'll be able to view the revenue data for the 10 most popular products in your app, including one-month VIP fees, order quantity, full refunds, partial refunds, and annual revenue forecast (revenue over the past 30 days (payments – refunds) x 12). You can then click Download to export the detailed list in CSV format. At the bottom of the page, you can view the promotions in which users received discounts, including the number of products distributed for free and issued coupons.
Ø Purchasers page
The Purchasers page includes the buyer (user) data and ARPPU data. After clicking the Buyer tab, and selecting the countries and regions of interest (multiple choices supported) and time period (last day, last seven days, last 30 days, and all time), you can view the data for all buyers, new buyers, and returning buyers over the selected period. If you select All for all buyers, you'll also be able to see the total number of the buyers in your app. In the Buyers statistics by product table, you'll be able to view the number of buyers, and the period-on-period growth rate for the top 10 in-app products.
Ø Conversion page
After clicking the Conversion rate tab and selecting the countries and regions of interest (multiple choices supported), you'll be able to view the user account payment rate (number of accounts making purchases/number of devices with your app installed) over the past 30 days, 6 months, 12 months, and all time in all stipulated locations.
On the ARPPU page, you can opt to view the data for countries and regions of interest (multiple choices supported), and by currency (CNY, USD, and, EUR). After setting these filters, you'll be able to view the ARPPU values and their period-on-period growth rates for the selected locations over a specified period of time. All the data will be displayed in descending order by ARPPU.
In the Payment rate table, you'll find the average payment times per user per month and average payment amount per user per month for your app. The data provided by IAP provides key insights into user demand and purchasing habits, while offering a host of fine-tuned filters to hone in on individual products and specific time periods.
For more details, please go to
l Our official website
l Our Development Documentation page, to find the documents you need
l Reddit to join our developer discussion
l GitHub to download demos and sample code
l Stack Overflow to troubleshoot integration-related issues
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Introduction
Before I begin, if you are not coming to this article from the Part 2 of the series, you can read here. If you have not seen part 1 either, you can click here. This is the third part of our HMS Unity Plugin 2.0 integration guide. This time I will be talking about in-app purchases, i.e. IAP. In the part 2 of the series, I already integrated many kits to my simple game but one important element has been missing: IAP. I will integrate IAP so that users can spend money on items in my app and you can make revenue out of your game.
I will, again, try to keep it brief and use a simple scenario. I will be implementing two types of products. One of which is a consumable and the other is a non-consumable. As you might now, in IAP, there are three main categories, two of which I already have given the names of and the third is subscription. All of them are self explanatory; for example, a consumable is a coin that can be spent and re-bought, a non-consumable is a premium membership that can be bought once and will not be lost, and a subscription is a subscription to a music or video service.
Since my game is simple, to try out more than one category, I use “heart” as a consumable purchase and “remove ads” as a non-consumable purchase. That is, since my game has hearts on the left upper corner to track how many lives of the player is left, I add an in-app purchase to buy one heart. Also, since I use ads, I will use a remove ads purchase option and if the user buys it, I will remove the ads from the game.
Let’s get started!
IAPBefore going into coding phase, there are important things that you should do.
Sandbox TestingAfter I am done with the whole IAP process, I will have to test whether I implemented everything right. However, since this is IAP, I would need a credit card and purchase every time in real money, even for test purposes. This is not optimum because then, I would need funds and the refunding process takes a bit long for testing.
Huawei offers “Sandbox Testing” for this type of scenario. You need to configure a sandbox testing account for the account that you use to publish your game in App Gallery. For all the details, please click here. This is not essential for IAP to work but it is a very useful feature for testing. I strongly suggest you configure this before testing. I will not talk about the details here but the link should have it all.
Merchant Account and Other SettingsIAP requires a merchant account in the App Gallery side. For the general walkthrough in official docs please check here. For the merchant account, you can check here. Naturally, for the money you earn to be transfered to your account, you would need to provide your bank details to App Gallery. Links have the details and from now on, I will assume you have completed these steps, so we can code together in peace.
Coding PhaseLet’s get to coding in our app. You need to determine your specific scenario where you want to implement IAP and which kind of products you will offer to your users. I already talked about my scenario, so let me show you how I configured my app to implement that process.
Implementing a Pause MenuI added a pause menu to my game so that whenever users want to buy additional hearts to survive longer or to remove the a-bit-annoying ads, they can do so by pausing the game. I added button to that menu and implemented button clicks to direct them to App Gallery UI for IAP and then to grant them what they just bought.
Now that my pause menu is ready, I need button clicks. But before that, just like achievements in part 2, I need to add my products to the App Gallery Connect. Plugin will help me get those products easily thanks to its IAP tab in HMS Settings menu. So, before adding some button clicks let’s go to AGC and add our products.
Adding Products to AGCWhat you first should do is to go to AGC console by clicking here, sign in and then go to My Apps and then choose your game. You will be directed to “Distribute” tab. From the left-upper bar, choose “Operate” tab instead. There, you will have “Product Management” tab opened at first, which is where you will add your products.
Click add product on the right-upper corner and enter the details of the product that you think is suitable for your own game. Please also consider the scenario where and when you will allow your users to buy this product because it can slightly change your product details.
My remove_ads example can be seen above. I very simply provided a name and explanation. The most important thing here is the product ID because I will reach our product from the game using that ID.
Adding Products to PluginAfter I add both of my products, now it is time to set up the plugin constant class. For my case it may look redundant because the IDs of my game is short and there are only two of them anyway, so they are easy to remember. However, plugin is designed to help all kinds of developers, also to those who may have over a thousand IAP products in their apps. It basically provides ease of use.
So, I open the HMS Settings from the Huawei tab in Unity editor.
You simply should select the type of the product and enter its ID. ID must match the ID that you used in AGC. You can also import all your products, if you already have a game on Google Play Store by downloading the report and importing it to HMS Unity Plugin 2.0.
“Initialize on Start” will call certain functions at the beginning of your app and make the IAP ready for you. If you tick the box, you do not have to worry about the IAP initializations that are normally required, plugin will do it for you.
In a scenario where you do not want this to be your default behaviour (for instance, in cases of huge load on Start() function etc.), you can leave it unchecked because it is also possible to manually initialize IAP service. For this please refer here, the official readme of the plugin. There are just a few things that you should do. If you do them, you should be good to go and use the IAP as usual.
And that’s it for the HMS Settings part. Now to code in C#.
Implement Button Clicks and CallbacksWhat is left to do is to implement the button clicks for purchasing the products. But also, implementing a success callback is a must because that callback is where I will implement my post-purchase logic. It may differ from one app to another, so I will show you my logic and you can infer what to for your own case.
In a separate script, or in a script that you think is suitable, I need to first register to callback. Since I have the plugin on my side, we do not have to deal with anything else, especially if you ticked the “Initialize On Start” box. The products will be retrieved from AGC in the backend, so what you should just do is to call purchasing functions.
Code:
void Start()
{
//...
HMSIAPManager.Instance.OnBuyProductSuccess = OnBuyProductSuccess;
}
public void BuyProduct(string id)
{
HMSIAPManager.Instance.BuyProduct(id);
}
In the code above, I registered to success callback and made a function call my actual function to buy the product. I did it this way to implement a button click but normally one line code as shown below is enough:
Code:
HMSIAPManager.Instance.BuyProduct(HMSIAPConstants.remove_ads);
I also should add the callback, where I will implement my post-purchase logic.
Code:
[HideInInspector]
public bool isAdsRemoved = false;
private void OnBuyProductSuccess(PurchaseResultInfo obj)
{
string myProductId = obj.InAppPurchaseData.ProductId;
//Implement your own logic here... The following is my logic
if(myProductId.Equals("heart"))
{
GameObject.Find("Player").GetComponent<Player>().health++;
GameObject.Find("Player").GetComponent<Player>().updateHealthDisplay();
} else if (myProductId.Equals("remove_ads"))
{
isAdsRemoved = true;
}
}
In the success callback, assuming that I have no server side implementations, I will get my product id to see which product the user has purchased. The rest is completely up to you because it is where you implement your own logic.
What I did is, if the user has purchased a heart, I increment his health by one and update the health display on canvas.
If the purchased product is remove ads, I set my boolean variable to true. I use this wherever I show ads to user in an if check, so if the user has purchased the “remove_ads” product, s/he will not see the ads in my game.
Tips & Tricks
Normally, a non-consumable product, once purchased, cannot be purchased again. However, in Huawei Sandbox Testing, you are able to purchase the non-consumable (remove ads in my case) product again.
If you are unsure about whether you successfully registered in the sandbox testing environment, you can try purchasing a product in-game. You will be directed to IAP UI and before you can try to buy anything, you should see a warning message, like below, if you are in sandbox testing. If you do not see anything and the app wants a credit card, then, your sandbox testing process is failed and you are advised the visit the steps again.
ConclusionThat’s it we successfully integrated IAP to our game together! The users will be able to do in-app purchases in the game and we can even start making money!
If you have completed other two parts of this article series too, your game is now empowered with Huawei’s powerful kits and that is with the ease of low development cost, thanks to HMS Unity Plugin 2.0.
I hope that this article series have been helpful for you. You can always ask questions below, if you have anything unanswered in your mind.
Good luck on the store and see you in my other articles!
References
IAP Official Documentation
Sandbox testing environment setup
Original Source
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Ads are everywhere and we can't escape them. They're on road billboards, shops, buses and buildings. If a world filled with ads sounds daunting and you want to hide indoors, just beware that ads will even jump out at you from your TV, computer, or phone.
It's likely that ads will be around with us for forever. Ads are often seen as annoying, but they can in fact be very helpful. If you are looking for a job, want to go somewhere fun, or are not sure what special thing you can get for your other half's birthday, ads may in fact provide some inspiration to you.
Nowadays, ads are transforming in appearance and purpose. Ads are becoming more intuitive as they are able to target specific audiences. For example, ads about quick fashion will target young adults, while some ads are typically pushed to males. This is an advanced advertising mechanism for brands, media, and users, where all can benefit. Someone gets traffic, someone makes money, and someone gets what they needed. Under ideal conditions, ads, under control and without harmful information spread, mean a lot for us.
As an app developer, I have been trying for a long time to request ads in my app to monetize the traffic and increase revenue. Recently, I encountered some obstacles with the ad traffic monetization data of my own app, and I have been searching for tools to obtain data and analyze ad performance. Collecting such data and then deciding how to analyze ad performance was no easy task, and this was complicated by the many tools and plugins needed to do so. I have used some of the tools found in the industry, but their performance rarely satisfied me.
But I eventually came across a very useful tool, the Publisher Service Reporting API of Ads Kit provided by HMS Core. The traffic monetization service helps me display various ad formats, such as banners, native ads, and rewarded ads, to my users. Routine data tracking is crucial for me to boost revenue. What's more, the Reporting API is key to obtaining ad monetization data, including ad requests, returned ads, impression rate, and click-through rate. I can analyze ad performance based on this data and adjust my monetization strategies accordingly.
But how did I acquire traffic monetization data? Here I'll tell you how I did it.
Implementation Procedure1. Obtain the client ID and key.
Before obtaining the monetization data, prepare an OAuth 2.0 client ID and key, which are needed for generating the access token passed for calling the Reporting API.
Note that the client ID and key are not those in App information (shown in the following red box) in AppGallery Connect, instead, the client ID and key of the server app created under HMS API services > Credentials on HUAWEI Developers.
a. Register as a developer and complete identity verification.
b. Sign in to the console, choose HMS API Services > Credentials, and create a project. If you already have a project, directly select it.
Click the drop-down arrow at the top, click New project, fill in the project name and alias, and click OK.
Select the project you created and click OK.
c. Choose OAuth 2.0 client ID.
If an OAuth 2.0 client ID and key already exist in your project, you can check whether the product type is server app by clicking Edit in the Operation column of the project. If so, skip step d.
If your product is not a server app, you should create an OAuth 2.0 client ID.
d. Select Server app from Product type, set Product name, App type, and Default language, and click Create. In the Note dialog box that displays Client ID and Key, click Confirm.
e. Go to HMS API services > My APIs, ensure that the project is the one you created, and click Add API from library.
f. Click Publisher Service Reporting API under App Services.
g. On the page displayed, click Enable to enable the API. Then you can call the API.
If you disable it and then enable it again, the setting does not take effect in real time due to page cache, for example. The setting will take about 6 to 10 minutes to take effect. If you have waited for longer time, try again.
2. Call the Publisher Service Reporting API.
a. Obtain an access token.
Call this API:
POST https://oauth-login.cloud.huawei.com/oauth2/v3/token
Request example:
Code:
POST /oauth2/v3/token HTTP/1.1
Host: oauth-login.cloud.huawei.com
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials&
client_id=<Client ID>&
client_secret=<Client secret>
Screenshot:
Note that again: the client ID and key are those of the server app but not those of the mobile app created.
b. Call the Reporting API.
POST https://ads.cloud.huawei.com/openapi/monetization/reports/v1/publisher
If you are in Russia, call this API:
POST https://ads-drru.cloud.huawei.ru/openapi/monetization/reports/v1/publisher
Request example:
Code:
POST /openapi/monetization/reports/v1/publisher HTTP/1.1
Content-Type: application/json
Authorization: Bearer ***
Accept: application/json
Content-Length: 233
{
"start_date": "2022-06-01",
"end_date": "2022-06-28",
"filtering": {
"currency": "CNY"
},
"time_granularity": "STAT_TIME_GRANULARITY_DAILY",
"page": 1,
"page_size": 10
}
Screenshot:
As shown in the preceding figure, the data is successfully returned. For more request parameters and response parameters, click here.
In addition, I can customize data display formats to suit my specific app scenarios.
Some Problems You May EncounterWhy was message "access forbidden" returned during the API calling?
Some Problems You May EncounterWhy was message "access forbidden" returned during the API calling?
Possible causes:
You have not enabled the Reporting API.
You have not been authorized to call this API, or your permission has not taken effect yet.
The client ID and key used for obtaining the access token are not those of your server app.
My solutions:
1. Click Add API from library under My APIs and enable the Reporting API.
2. If you disabled and enabled the API again, you may need to wait for 6-10 minutes before the setting takes effect.
3. Check whether your client ID and key belong to a server app when you obtain the access token. To find out it, check the app type on the Credentials page. If it is not a server app, create one and use its client ID and key to request an access token.
ConclusionIf you also think obtaining ad monetization data and dealing with ad issues are annoying as me, you can try this tool to help you in daily work to obtain data and help you in subsequent operations. Hope that my procedure and experience can help more guys and you can also find out more useful methods.
HUAWEI In-App Purchases (IAP) enables you to sell a variety of virtual products, including consumables, non-consumables, and subscriptions, directly within your app. To support in-app payment, all you need to do is integrate the IAP SDK and then call its API to launch the IAP checkout screen. Below are some frequently asked questions about IAP and their answers. Hope they are helpful to you.
Q: A monthly subscription doesn't reach the end of a subscription period, and is changed to a yearly subscription in the same subscription group. After I visit the Manage subscriptions screen in Account center and cancel that monthly subscription, the yearly subscription is also canceled. Why is this?A: The yearly subscription doesn't take effect until the end of the subscription period during which the subscription change operation is made. So after you cancel the monthly subscription, the yearly subscription that hasn't taken effect will also disappear. Your app will receive a notification about the cancelation of the monthly subscription. As the yearly subscription hasn't taken effect, no relevant cancelation notification will be received.
Q: My app tries to bring up the IAP checkout screen on a Huawei smartwatch, but only receives a message telling me that some HMS Core services need to be updated. After I update it, the update fails (error code: 102).A: This error code generally means some kit updates are needed, but no relevant packages are found from HUAWEI AppGallery for smartwatches. If your app running on the smartwatch has integrated the IAP SDK for HarmonyOS (JavaScript), two services need to be updated: JSB Kit and IAP Kit. JSB Kit has already been launched on HUAWEI AppGallery for smartwatches, but IAP Kit still needs some time.
Here's a workaround for you. Make your app request that users download the latest HMS Core (APK) from HUAWEI AppGallery for smartwatches. (See error code 700111, API call error resulting in the update failure.)
Q: IAP has two SDKs: one for Android and the other for HarmonyOS. Are there any differences in the functions and devices supported by the two SDKs?Both SDKs provide basic IAP services, including managing orders, making subscriptions, and viewing purchase history, but the SDK for HarmonyOS temporarily does not support non-PMS payment or pending purchase. (PMS stands for Product Management System) In terms of supported devices, the SDK for HarmonyOS supports Huawei phones, smartwatches, and tablets, and the SDK for Android supports not only the devices mentioned above but also non-Huawei phones and head units.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Q: I find that the obtainOwnedPurchasesRecord API in IAP SDK 4.0 or later fails to query non-consumables managed in the PMS and purchased through the productPay API in IAP SDK 2.x. Why?A: Data of IAP SDK 4.0 or later and that of IAP SDK 2.x is stored in different databases and temporarily cannot be migrated to the same one, so the problem you've found arises.
Here's a workaround for you. If needed, make your app show only the data generated after IAP SDK 4.0 or later is integrated. For example, if you have integrated IAP SDK 4.0 or later on January 1, 2022, tell users that the starting day of their data query can only be January 1, 2022 or later.
A better way is that you can merge data of IAP SDK 2.x (obtained from the app server) with that of IAP SDK 4.0 or later (obtained through the IAP SDK API) depending on your situation, such as using the same data type for them and placing them on the same server.
Q: During sandbox testing on a Huawei smartwatch, the QR code for payment does not appear after the IAP checkout screen is displayed, and an error indicating incorrect request parameters is reported. What should I do?A: Payment through QR code scanning such as on a smartwatch or smart display, is temporarily unsupported in the sandbox environment.
If you do need to test the mentioned payment method, sign in with a non-sandbox account (or if you have only one account, remove it from the sandbox environment) and test the relevant functions in the production environment.
For more information about HUAWEI IAP, please visit the HUAWEI Developers website. Or you can directly click here to find more IAP FAQs.
HMS Core In-App Purchases can be easily integrated into apps to provide a high quality in-app payment experience for users. However, some developers may find that the payment screen of In-App Purchases cannot be opened normally. In this article, I will explain possible causes for this and provide solutions.
Scenario 1: In-App Purchases has been enabled on the Manage APIs page in AppGallery Connect, and the created product has taken effect. However, error code 60002 is recorded in logs.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Cause analysis
The payment public key is required for verifying the SHA256WithRSA signature of the In-App Purchases result. However, the developer has not configured a payment public key.
Solution
Check the following items:
(1) In-App Purchases has been enabled on the Manage APIs page. (The setting takes around half an hour to take effect.)
You can visit the official website to see how to enable the service.
(2) The public key switch is toggled on, and the public key is used correctly.
(3) The corresponding product category has been configured on PMS in AppGallery Connect, and has been activated successfully.
Scenario 2: Error 60051 is reported when the developer opens the subscription editing page in the member center.
According to the official website, error code 60051 indicates that a non-consumable product or subscription cannot be purchased repeatedly.
Cause analysis
After a subscription is completed, there is a refresh action when going back to the member center. An error will be reported if the subscription button is tapped again before the refresh occurs. The product can only be successfully subscribed to if the subscription button is tapped after the refresh. This is because if the refresh action is not triggered in time, cached data of the previous subscription will still exist. If another product is subscribed to immediately after a product is subscribed to, the ID of the previously subscribed product will be passed to the system instead of the newest product. As a result, an error is reported and the subscription editing page cannot be displayed due to product ID mismatch.
Solution:
Modify the timing for triggering the refresh action to prevent product subscription from occurring before the refresh.
Scenario 3: Error code 60003 is reported when a Huawei phone is used for payment debugging, but the product ID is correctly configured on PMS.
Cause analysis
Generally, error code 60003 indicates that the product information configured on PMS is incorrect. You can sign in to AppGallery Connect, click the desired app, go to Operate > Product Management > Products, and check that the corresponding product exists and mandatory information (such as the name, ID, price, type, and status of the product) is configured correctly.
In addition, you can check whether the product ID is correctly configured in the client code and consistent with that in AppGallery Connect. In particular, check that the field passed to the client code is correct.
Check whether the service region of the HUAWEI ID signed in on the Huawei phone supports In-App Purchases. To do this, call the Task<IsEnvReadyResult> isEnvReady() method.
Solution
After troubleshooting, the developer finds that the error is reported because the product ID passed to the client code is inconsistent with that in AppGallery Connect. After correcting the product ID in the client code, the issue is resolved.
Scenario 4: The payment screen is opened successfully when the checkout start API is called for the first time. However, after the payment is canceled, the payment screen fails to open when the API is called again.
Cause analysis
After a consumable product is purchased, the product can be purchased again only after the purchased product is consumed. Otherwise, error codes such as 60051 will be reported.
Solution
Redeliver the consumable product.
You need to trigger the redelivery process when:
The app launches.
Result code -1 (OrderStatusCode.ORDER_STATE_FAILED) is returned for a purchase request.
Result code 60051 (OrderStatusCode.ORDER_PRODUCT_OWNED) is returned for a purchase request.
Result code 1 (OrderStatusCode.ORDER_STATE_DEFAULT_CODE) is returned for a purchase request.
If the refund callback URL configured in the In-App Purchases configuration page is incorrect, reconfigure it correctly. You can click here for details.
In addition to the payment screen opening failure problem, another common problem is how to determine whether the sandbox environment is entered.
Scenario 5: A sandbox account is used for testing but no sandbox environment popup is displayed. How to check whether a sandbox environment is entered?
Cause analysis
Generally, a popup similar to the following will be displayed when the sandbox environment is entered.
The two mandatory conditions of the sandbox environment are met but still no sandbox environment popup is displayed. Does this mean that the sandbox environment is not entered?
The screenshot below shows relevant logs for the isSandboxActivated method.
According to the logs, the two mandatory conditions of the sandbox environment are met, which are:
The currently signed in HUAWEI ID is a sandbox account.
The version code is greater than that of the online version on AppGallery. (The APK has not been released to AppGallery. Therefore, the version code returned by AppGallery is 0.)
Theoretically, the sandbox environment has been entered. Are there other methods to check whether the sandbox environment is entered?
Solution
Check whether the sandbox environment is entered successfully using the following methods:
a) Check the returned purchase data, as shown in the screenshot below.
If the Huawei order ID specified in payOrderId begins with SandBox, the order is generated in the sandbox environment.
b) Check the payment report.
Check whether the payment report contains this order. If not, the order is generated in the sandbox environment. (Note: Data on the payment report is not updated in real time. If the order is placed on the current day, the developer can check the payment report on the next day to ensure accuracy.)
c) Clear the HMS Core (APK) cache.
You can try to clear the HMS Core (APK) cache. The system determines whether to display the sandbox environment popup based on relevant fields, which may not be updated in time due to the cache. You can go to Settings > Apps & services > Apps > HMS Core on the device to clear the cache.
References
In-App Purchases official website
In-App Purchases development guide