IAP
IAP are In-App Purchases, virtual items that you sell for real money and that will allow you to further monetize your game.
As for AdMob, they require you to handle a huge part of the configuration out of Construct 2, directly into the Google Play Dev Console.
For this tutorial, let's take the example that we are going to provide an "Ad removal" IAP that once bought will hide our AdMob ads to the user.
In a free game, monetized by ads, it does make sense to provide such an option to the player.
I would recommend to keep implementation of the IAP as one of the later stages in your game, once you have an already complete game that is working as intended, with HUD, menus, etc...
The process of trial and error while testing can be very frustrating because of a wait period imposed by the store and consecutive builds, but it cannot be done otherwise unfortunately.
Nevertheless, I'll try and detail everything you need so you have close to no issue while implementing your IAPs on Android.
Setting IAP in the Dev Console
First thing first, each item you will offer for purchase in your game has to be created/managed from within the Google Play Dev Console, in your game's page.
To be able to provide IAPs, you will have to attach a "Google Merchant Center account" to your Google Dev account if you haven't already.
This documentation page will display what country allow you to register as a Google Developer AND a merchant.
This documentation page will let you know how to link a Google Play Dev account to a Google Payment Merchant Center account if you haven't already done it.
Once done, go to your application's page in the Console and in the left column click on "In-app Products".
In the main area, on the right, you have a blank list.
On top right next to the title "IN-APP PRODUCTS" a button "+ Add New Product". Click it.
This opens a new dialog allowing you to set the informations for your product.
The first thing to set is whether you are creating a "Managed product" (one-time purchase) or a "Subscription" (recurring fee).
Play Store does not provide you with the option to buy "Consumable" items per say.
You will either have to handle it through code in your game, or just run with the provided options.
The Managed product, once bought stays in the user's account, allowing for a check from the game to see whether the item has been purchased or not.
Depending on the answer to that check, you can decide of what happens.
To get back to our implementation example for this tutorial, let's consider the "Ad Removal".
It will be a "Managed product". When checked and the user doesn't have bought it, we display ads in the game. When checked and the user has bought it, the ads is hidden so the user never sees it.
You can set the item to be a "Subscription" that will require the user to pay a recurring fee for the same effect.
Payments and payment flow is handled by Google itself through the same means used in the general Play Store, so the user faces a consistent interface.
(Note this photo displays a test IAP dialog in French. The mention is there to let you know it is a test purchase that won't be charged for real.)
To get back to our product, we are asked the Product ID. It is a basic string, as notified, that must be unique and cannot be edited later on.
This is the ID we will need to use in our Construct 2 code to know that we want to purchase this product.
We can keep it very simple and name it "remove_ad".
Once the type and the Product ID typed in, the Continue button is ours to click.
The main area updates and allows us to fill the verbose informations in.
The displayed (human readable) name for the product (Title), its description so our users can be aware what they are buying before buying it, and its price.
Notice that by default the informations are set to your default language and can allow you to set a translation as well.
You may want to keep this for later or simply rely on Google Translate (although results may have a very different meaning than what you originally meant).
You can set the price for your product, in your default currency.
Scrolling down you will see a table that sets the price per country, depending on the taxes and currencies.
You can click the "Auto-convert price now" button to automatically fill in the table according to your set price.
You can always come back later and edit each one individually.
The price will be displayed to the user in the IAP dialog before any purchase is made.
On very top of the page you can notice two buttons.
One, obvious, is named "Save" and the other, a drop-down list, "Inactive".
We want to set the product as "Active" for it to be purchasable.
So drop the list and click "Activate".
This does also automatically save the product.
It is going to be reviewed as well, so you are notified it may take several hours before the product is available. The wait game starts here, but we currently have far more to do.
If you click back on the "In-App Products" menu on the left, you can see now a table that contains the product we've just created.
And you can create as many IAP as you want.
From there, let's see how to implement IAP code-wise in our Construct 2 project.
Using the IAP plugin in Construct 2
Note: Please make sure that you use at least Construct 2 beta r218 or higher for this to work.
In r128 a fix was applied to the IAP plugin that made "Has product" work, whereas it would fail in prior versions.
There are still a few known bugs that need to be worked out, and will likely be in the next releases.
But the implementation and method for this tutorial do work as intended !
Now, we need to add the IAP plugin to our Construct 2 project.
Fortunately, there is little as far as configuration/properties go.
Like for AdMob, a property "Test mode" is by default set on "Yes".
It means that any purchase will be made in test mode, if the targeted store supports it.
Fortunately our current store "Play Store" does allow this sandbox testing.
So now all that is left is to use the plugin in the events sheet.
As notified in its manual article, the IAP plugin is made to support several stores at once.
And each store has its own ways.
Nevertheless, on the very "Start of layout" of the first layout of your project, do add the action "Request Store Listing".
This is always nice to see what's going on and will allow you to obtain the correct result out of the condition "Has product" that we are going to need and use.
The "On Store Listing Success" trigger should be another event you add.
Once this trigger goes on, you know you have made contact with the store and the "Has product" condition will work as intended when provided with a correct Product ID (the very same as the one we've set for each IAP product in the Dev Console earlier).
You can use this event with some variables to let you know code-wise that you can proceed further on.
We've said earlier that our project was to use IAP as an advertisement removal.
To get back to our implementation example for this tutorial, let's consider the "Ad Removal".
When 'Has product "remove-ad" (same Product ID as the one we have set in the Dev Console)' is true it means the product has been bought and we don't want to display the ad. We can then use the "Hide ad" action of the admob object. Or in the case of an interstitial ad, just decide to do nothing (not display it).
On the other hand, right-clicking the condition and selecting "Invert" allows to make the inverse condition "When the user has not bought the product of Product ID "remove-ad"" and so as action we do display ads from the admob object as seen previously in the tutorial (in the case of an interstital ad, that is where you display the ad).
In term of implementation for this very mechanic, that is about it.
I invite you to check out the commented file "adMob_IAP_Android.capx" (made in r218) added to the resources of this tutorial (left column).
It is an example of implementation of ads and interstitial with usage of the IAP for Android.
Now, like for the previous project with AdMob only, you can export as Cordova and pass the files into Intel XDK (please refer to earlier in this tutorial for these specific steps are they are the same).
Our IAPs in Intel XDK
I invite you to go back to the previous part in this tutorial named "Exporting your game through Construct 2 and Intel XDK" on how to set up a complete project and how to use Intel XDK if you are not yet familiar how to do it.
This part there only focuses on the required steps to have the IAP working.
In order for the IAP to be recognised when exported as CrossWalk Android from Intel XDK,
you need to add a third-part Cordova plugin to your project.
So in the "Plugin management" tab of your project's properties, click the "Plus" icon "Add Plugins to this Project".
This time in the left column select "Third-Party Plugin".
The main part of the dialog changes and allow you to specify the plugin by its ID (Cordova plugin registry), by the GitHub address of its repository (Git Repo) or import files you have downloaded (Import local plugin).
For this time, we are going to select "Git Repo" and put the GitHub URL of a repository.
When selecting "Git Repo" the fields to fill change. We are only going to need to fill the "Repo URL" field.
Input the URL "https://github.com/poiuytrez/AndroidInAppBilling" in this field.
Click the blue button to the down right : "Add plugin".
A new dialog appears letting you know that the plugin is being downloaded to your project.
After a while, a new dialog named "Missing required variables" appear, and ask you to fill a value for a "key" named "BILLING_KEY".
The value to put in that field is found in the [Google Dev Console]2.
Go to you application, and in the main space, left column, click "Services & APIs".
The first time you access this part you'll be ask to click a button to confirm.
Read everything written and click the button.
To be honest, I don't have access anymore to that aspect so I can't tell further about it.
This is the only time you will be asked to click the button after accepting some Terms of Service or forewarning that the informations in this category are very critical and should be kept secret at all time.
And in the main space you will find a paragraph "Licensing & In-app billing" with a "Your licence key for this application" followed by a big list of characters in a grey background.
This is the key that is the value expected in XDK currently.
Select it (make sure to select only the characters and select ALL the characters) copy it (ctrl+C) and paste it in the dialog (ctrl+V).
Click the "OK" button and then you should be granted with a dialog named "Plugin added successfully", containing the name and ID of the plugin, its version, author, CLI version, the Billing Key itself and the Android permissions that will be asked when installing the application.
Adding this plugin do make your application require a "Billing permission", let the user know there are InApp purchases in your game.
And that is actually all that is specific to IAP in XDK.
The rest is as described previously, so, again, if you are not familiar with the process yet, I'll let you go back to the previous part of this tutorial named "Exporting your game through Construct 2 and Intel XDK" that describes the setting of the project's properties, the values that absolutely need to be modified each time you make a new build and finally the building itself.
Our next step with IAP, is once you have built and download your APK file, publishing it into the Google Dev Play Console and setting accounts that are allowed to test them.
Testing IAPs
To be able to test them, it is also critical that your game is published as Alpha/Beta, that you have a list of set testers (as mentioned previously) and that the App Code Version installed on testing device (using a valid address of a tester) is the same as the version published in Alpha/Beta.
This means that to be able to test purchases, your current APK must be uploaded to the Play Store and validated (displayed as "Published").
Then testers may either download/install/update the current version directly from the Play Store page (link is found in the console in the application page right under the title of your game; Link named "View in Play Store") or manually install the APK you provide them.
You can find exact steps on how to do so in the previous part of this tutorial named "Adding your game to Google Play Developer Console"
As far as I'm concerned, I found it easier to update directly from the Play Store while I was testing.
At times, the update even happened automatically along the other updates of applications from the store.
This also means that each time you build a new APK, you will have to wait a few hours that the new build is reviewed, accepted and published on the store before being able to actually test it out.
Nevertheless, once you have uploaded a few times, your upload will take only a couple of hours to go through submission review allowing you to work on something else in the meantime.
Having your game published and using the very same version on your device as the version published in the google dev console will allow you to display the Google IAP purchase dialog when trying to do a purchase, and will allow the C2 IAP plugin to "Require Store Listing" and see if "Has product".