In-App Purchase Question

[William Spence]

With Apple, in-app purchase is not an option, it is a requirement if you want to unlock content or add a subscription.  Try to get around it and your app will be rejected.

I cannot figure out if the same is true for Android.  It almost seems as if in-app purchase is a convenience mechanism for the developer to have some way to collect money on games or services using the platform if you want to use it, but I don't see in the documentation that it is a requirement and that your app will be rejected if  you try to use Stripe or some other payment mechanism.

Does anyone know if you HAVE to use in-app purchase on Android to collect money for services or to unlock content or to add a subscription?

Thanks for any insights!

[rewb0rn]

You should find answers to your questions here:

Monetization and Ads - Developer Policy Center

Among other things, apps that fall into the game category are required to use the Google Play IAP API.

[William Spence]

Thanks rewb0rn. It is odd, my app is a real estate app that accepts subscriptions, and it currently uses Stripe as my payment method. Once Apple figured this out, they started rejecting my updates. So I am in the process of updating my apps to be in-app purchase compliant. But Android is even weirder because I don't believe that they actually have humans involved much in the review process, so everything has been accepted using Stripe so far. But I really don't want this to bite me in the butt later, so I just want to be compliant right out of the gate So I don't have headaches in the future.

According to what you posted, it looks like subscriptions have to use in-app purchase to be compliant on Android.  My ANE for in-app purchases just has options for Android and Apple, nothing specific for Amazon. Does anyone know if you have to make a totally different billing system for Amazon Android products, or will doing it with Google work across all Android devices?

[Flipline]

Amazon does have a completely different billing system, the Google in-app purchases will not work in an Amazon version.  Amazon does provide their own Adobe AIR ANE to use here:

Adobe Air Plugins and Extensions | Cross-Platform Plugins

[William Spence]

Thanks for the link Flipline, EXTREMELY helpful.

So last question.  How can I test whether the device is an Amazon Kindle or not?  I know that I can use Platform.isIOS to test if the app is running on an Apple device and can call the right functions to deal with the Apple App Store.  I know I can use Platform.isAndroid to test if I am running on Android, but how do I test to see if it is a Google Play device or a Amazon Kindle device???

[Flipline]

In the version that we submit to Amazon we only have the Amazon code and don't have any of the Google Play code (which may even be a requirement for Amazon, I'm not sure exactly). So if the user gets the app on a Kindle Fire from the Appstore it will use Amazon's purchase system, and if they installed it on some other Android device using the Android app for the Amazon Appstore it also uses the Amazon-based purchases and doesn't switch over to Google Play.

We tend to use conditional compilation for this, so we can toggle which store we're targeting as we publish from Animate or FlashDevelop, and it'll only include the Amazon code when we publish the Amazon SWF/APK, and only Google Play code when we're publishing an Android version to submit to Google Play Store, etc.

[rewb0rn]

You don't make the decision in your code at runtime. You upload a different apk to Google and Amazon respectively. So one time you compile a build for Google Play IAP and one time you compile a build for Amazon IAP.

[William Spence]

Ugh, fellas, this wasn't the answer I wanted to hear   I am a single developer, so I tend to like to have only one code base, which is why I chose to develop in AIR.  Your solution will take me from having three code bases for three apps, to having to maintain at least 6.  Are you sure there is no other way to test the device at runtime?

[Flipline]

I don't think there is, Amazon recommends using PackageManager getInstallerPackageName for native Android apps to determine whether it was installed from Google Play or Amazon, but AIR doesn't have access to this information unless there's an ANE somewhere that adds this.

If you're publishing for both iOS and Android you already have to go through the process of packaging one version as an ipa and one as an apk, so we just think of Amazon as a third separate platform and plan our publishing accordingly.  If you separate the Amazon and Google Play code with conditional compilation, in the end you just need to set one variable or click a checkbox before you hit Publish, then do it again with a different variable and hit Publish again, so it can be fairly streamlined.

[William Spence]

Flipline, I kind of understand what you are saying, and kind of don't. I already keep one code base and either export the app for Apple or Android as you suggest, which is easy as pie.  I will be able to keep doing that with the ANE that I have for in-app purchases, which can test whether I am using an Apple or Android device and use the ANE accordingly, so I will still be able to export as either IPA or APK, easy peasy.  But now, I will have to keep a separate code base with an Amazon ANE for in-app purchases, and Amazon functions to handle the purchases, and export this to an APK for Amazon.  This means that if I add any new features or code to one app, I now have to add it to the Amazon version as well.  I call this inefficient.

I would much rather have one code base and ask questions like this:

If this is an apple device {

     run Apple in-app purchase code

} Else if this is an Android device {

     If this is an Amazon Android device {

          run Amazon Android in-app purchase code

     } else {

          run Google Play in-app purchase code

     }

}

Then I could keep all code under one roof, export it as an IPA or APK, and upload it to the appropriate App Store.  Of course, to do this, I need to know what kind of Android device Air is running on.  You guys are telling me that you do not do it this way, you just upload Google specific in-app purchase code to the Apple Play store, and Amazon AppStore specific in-app purchase code to the Amazon store, right?

[Flipline]

Yeah, we still technically keep all of our code under one roof and just have one master project, but we set it up so if I hit the "Android" checkbox before exporting, it will only export the Android code and not the Amazon code, and if I hit the "Amazon" checkbox it does the opposite.

Not sure if you use conditional compilation already, but you can set up variables in Compiler Constants (in project properties in FlashDevelop) or Config Constants (in Actionscript Settings in Animate), and then your code can reference those variables at compile time --- if you have one of them set to true when you publish, it will include any of that code when it compiles the SWF/APK.  So for example we have constants of BUILDTARGET::Android and BUILDTARGET::Amazon that can be true or false, and then in our code base we have something like this:

public function purchaseProduct(sku:String):void {

     BUILDTARGET::Android {

          //put android code here, it's only added to the compiled SWF if this is set to true when you publish

     }

     BUILDTARGET::Amazon {

          //put different Amazon code here, it's only added if your Amazon variable is true

     }

}

With Animate, you would just need to change the true/false values in Publish Settings > ActionScript Settings before you hit the Publish button, in FlashDevelop you do that in Project Properties, or there's a CONFIG::toggle plugin that lets you just click checkboxes before you hit the Publish button.

It's definitely a few added steps and some added work compared to one ANE that will handle all of that for you on its own, but once you get things organized with this process it's not too bad.

[William Spence]

Wow!  That is a super cool feature!!!  Sadly, I am using Flash Builder, and as far as I know, I have never heard of it having this conditional compiling feature.  I'll have to google it and see if Flash Builder supports this.  Very very nice for you.  May have to consider a switch at some point.  Thanks for all of your help today!

[Flipline]

No problem!  Flash Builder may let you add those config constants inline in the "Additional compiler arguments" section, I'm not too familiar with it but I did find this with a couple possible options in the replies:

Conditional ActionScript Compiling

[William Spence]

Flipline, you are a genius!!!  It works!  I can now keep all the code under one roof and just use conditional compiling to export the proper code.  WooHooo!!!

[William Spence]

One final question, I can redirect a user to Itunes to manage their subscriptions on an Apple device, where do I redirect users on Android and Kindle go to manage their subscriptions??  If it is in their App Stores, is their a link that will pop up the app store directly to subscriptions??

[marchbold]

You can redirect your user to this url replacing the sku and package name to match your subscription and application:

https://play.google.com/store/account/subscriptions?sku=your-sub-product-id&package=your-app-package

or just the generic page:

http://play.google.com/store/account/subscriptions

For information here: Add subscription-specific features  |  Android Developers