A little Amazon help

[Robert Valentino]

I would like to put my App up on Amazon.

When setting up the account (kind of like setting up App for Google), it wanted me to setup my InApp and Subscriptions (like Google).

My big question here is when billing happens is it happening through Google or Amazon?

We have Google Billing Manager, is there a Amazon Billing Manager that we have to incorporate in our code. When someone who has my App from Amazon purchases InApp and Subscriptions are Google & Amazon splitting there 30%? Amazon Developers program talks about the same 30% Google does. So it seems like they are getting their cut directly.

ALSO: Is there anything special about Amazon Fire Devices that I should know about (Screen, Storage, etc)

Before I complete the process just wanted some feedback

Thanks for any help

PS: Guess I should have said. That I've read all the posts on excluding RingTone etc. Getting a different billing stream (other then Google is what I would like)

 

[Robert Valentino]

Ran the Amazon test program:

When I click on the Caution it takes me to: https://developer.amazon.com/docs/in-app-purchasing/iap-implement-iap.html

 

[sorex]

most alternative stores want you to implement their own in-app purchases so that they can have their cut on sales.

the problem is that there are no B4X versions of those libraries.

amazon used to accept the AKPs tho while some simply reject your app.

 

[Robert Valentino]

I would like a different billing source. What happens like one person on this forum where google no longer wants your app

OR better yet someone like Amazon decides to take only 20%

I saw something where a new gaming (Fornite https://www.hindustantimes.com/tech...-and-google/story-x4wz0B27Qx6qahnSC4BbMP.html) site was starting up and they are just taking 12% - wouldn't you prefer for them to be doing your billing???

 

[sorex]

sure, the problem is that we need to rely on the goodwill of Erel and others to create the required libraries for it.

not to mention the misery to test all these and keeping them up to date.

maintaining all this ain't easy either.
now I have 1 app that goes onto several stores.
the first time it's a lot of work to add the entry as they all have their own specs for the screenshots.
what will you do when you start adding their own in-app stuff?
create a store specific APK based on a lot of conditional compiling? or a seperate project with the same main shared modules but a specific in-app class?

there's one exeption here... what used to be Aptoide has now a system that replaces your google in-app purchasing code with their own code.
I see 2 purchases there but I don't know if it actually removed the ads in my app aswell.
If the callbacks are not 100% the same then it will never reach my purchase completion code.
They also use APPCoin instead of $/€/... which is an Etheurium based altcoin.

 

[Robert Valentino]

Thanks for the feedback. Interesting comments. I myself would like to have my different streams of payments so that not everything goes through Google.

 

[Alejandro Moyano]

Why don't use something like PayU, for recurring payments, its pretty easy to integrate using HttpUtils2: http://developers.payulatam.com/en/api/recurring_payments.html or can use a checkout using a webview.

U may find that many payments gateways have easy to reach REST APIs, Skrill looks a nice multicurrency way but i think u may know who will be your users, i'm from south america and here new customers are more willing to put their creditcard on something with "MercadoLibre" logo than Google ones.

Gateways are more cheaper than google, but i don't know if they can ban the app by use it.

I just starting to do intranet apps then its just an idea, i never used outside PHP world.

 

[sorex]

but i don't know if they can ban the app by use it.

on IOS it's an instant rejection for sure.

Google Play guidelines also mentions that you MUST use their purchasing libraries when using in-app purchases in an app provided by their store.
I'm not sure it they test it like the Apple boys do tho.