In-app purchases allow developers to use the payment systems of app stores like Google Play and the App Store to sell virtual goods from within their apps. This is convenient for users, who can make purchases with one click, but app stores take a 30% commission and prohibit sales through other means. Setting up in-app purchases involves creating product listings with details like names, descriptions, and prices in the app stores' developer interfaces. The code to integrate purchases is relatively simple, with callbacks to handle purchase events, but managing the product listings can be cumbersome. In-app purchases are also required if apps attempt to sell any digital content or features.

1. In App Purchase
In app purchase is a relatively simple feature with a bit of hassle from the stores who handle the product management. The API itself is trivial

2. What’s In App Purchase?
✦ In app purchase allows us to use the Google Play or
iTunes billing system to pay for virtual goods
✦ This is a huge benefit as payment can be as easy as a
single click and very convenient
✦ It’s also a restriction, both Apple & Google prohibit the
sale of virtual goods in any other way!
✦ The drawbacks are: 30% commission & you can’t/
shouldn’t pay for non-virtual goods
Before we begin lets review the basics of what is in-app-purchase. In app purchase allows us to use the same billing support Apple & Google use for buying apps in
order to sell items within the app. You can use this to sell virtual goods which means things that are parts of the application such as digital content, upgrades, in-app
features, game elements etc.
Using in-app-purchase is much easier than credit card billing or any other form of payment as the whole process is managed by Google or Apple.
However, it’s also a requirement. If you have elements sold within your app you might get banned if you don’t use in app purchase. As an example we recently updated
the kitchen sink demo in the Apple appstore and got a rejection. The tester reviewed the link in the app to codenameone.com and complained that we sell items within
the site (the subscription) and don’t use in-app-purchase. We explained that that app is completely free and the subscription has nothing to do with the app and the app
passed the verification.
This should obviously teach you that communication in these cases is bidirectional and also how serious Apple is about the in-app-purchase requirement.
So why don’t we sell Codename One subscriptions via in-app-purchase. This is something we are actually considering but the main demotivation is the 30% commission
to Apple. They now have a special case for subscriptions that might make them more financially viable so we might add that in the future as an option but overall in-app-
purchase is expensive. If you are having thoughts about charging extra for in-app-purchase made thru the app that would be a problem as it’s prohibited by the Apple
terms of service.

3. Let’s start by looking at the code for in app purchase. Just like push requires the push callback in the main class, in app purchase requires the callback in the main class
too.

4. I’ll skip ahead to the callback methods for the purchase. itemPurchased is the actual purchase callback and it includes the sku representing the item that was purchased.
An sku is a constant value that you define when you setup the items in google play or itunes connect. The sku lets you determine the item that the user purchased when
you have more than one item. We are calling into the pending build method in this case to proceed with the purchase flow we started there. I’ll go into that soon.
We have an error callback as well which we can use for error logging. The refund callback might be interesting if this is a feature you can disable on refund but in this
case if a user asks for a refund there isn’t much we can do as the app was already built.
The rest of the callbacks relate to subscription and manual purchase callback which is no longer used. Subscription is a subject in its own right that I won’t get into here.
But it’s a very good direction as it allows a constant and steady stream of revenue.
Lets move into the AppForm code for purchase

5. The purchase UI shows a dialog with commands for purchasing an iOS, Android or source code build. For now we don’t support the iOS build but might provide this in a
future update. Based on the command selected by the user we can select the right target and perform the right purchase type

6. Once pending build is invoked it just invokes build app as usual. Since this is invoked by the purchase callback this is effectively seamless We could have used the SKU
value from the server and called the build app callback with the SKU which would have worked exactly the same as this.
As you can see the code is pretty trivial, the main hassle is dealing with this in Google’s and Apples interfaces

7. In Google Play after you’ve uploaded your initial APK you can select “In-app products”

8. We click “Add New Product” then select managed product which allows us to add a new product SKU

9. I type in build_for_android as the SKU, I can use an arbitrary string value to represent the SKU

10. I type in a name and a description for the item we’re selling, this will be displayed to the user as part of the native payment process by Google play

11. The next state is scrolling down to the price and clicking the add price button so we can enter the price for the item using the local currency

12. I set the price for 40 NIS which is mostly a trial and error thing of what google will generate in terms of the pricing table. Once this is set I can scroll to the top and save
the data and this in a nutshell is in app purchase.

13. Thank You
Thanks for watching. I hope you found this informative