ignored by Google - how to sell a $5 app ?

Facing an interesting dilemma here - lacking Google payment capability in our location, how to sell an app in the $5 price range.

If a whole host of companies can offer payment options WHY can’t Google do so for it’s developers ?
Worse, if Google has no option available for a region why does it PREVENT use of third-party payment options by those developers ?

The free payment options like GetJar are also showing very low payouts per app download - in my area GetJar payments for downloads have dropped from 10 gold coins per app download to 5 gold coins now (perhaps others can confirm if in the U.S. market they are seeing a higher coins per install figure ?).

The app I am thinking of publishing would be in the tools type category i.e. not have wide interest, but for the niche of users that user such apps, I am figuring that it may have features that could command a price much higher than $1.

At $1 I could consider a GetJar like solution - i.e. offer a free trial which expires and ads start showing - removable by earning 100 GetJar gold coins (i.e. $0.9 to the developer).

But what to do if you think you should charge $5 ? That would be like 100 app installs required (!) in my area (GetJar app download earning 5 gold coins only).

The right solution would be Google in-app payments or outright purchase of paid version of the app on Google Play store.

That option is not available.

Movend requires developers already have that capability, and there maybe some credit card/paypal/carrier billing solutions.
SlideMe maybe an option but requires users to login to SlideMe etc. - which adds steps that users have to take.

However, what are those - and the extra steps to redirect them to external sites will take it’s toll on conversion rates.

Altogether a very bad situation - and seriously raising the value of the Apple App Store (which DOES allow paid apps for our location).

What options are available ?

A simple one is to just go for $1 GetJar payment (or perhaps to use GetJar localized prices feature which MAY allow higher payment option which automatically gets reduced for lower paying regions).

And to port to iOS and try to charge $5 there …

Some of the talk of the Chinese market is interesting - esp. that of carrier billing - and that maybe something to pursue.

It seems the job of the individual developer is complicated by the need to be always on the move regarding monetization.

The situation cries out for combining developers with (a much smaller) monetizing team.

Sort of an incubator type situation for app developers.

In reality though it is probably more complicated than that - as successful monetization (esp. for games and in-app purchasing) requires that the app development really understand the monetization to begin with before they lay out the app plans.

What are the choices for publishing an app under a re-publisher’s account - there have been such urls floating around on the net (most seem to have gone out of business).

But it just seems that if Google supported such an arrangement it would have helped out folks immensely (or allowed a third party ad network to allow such a feature).

what about paypal integration? i used it for one app that was outside the play store and got it working well enough, though there is very little documentaion about how to implement online. it’s just a paypal login webview like facebook that you popup in your app

sales were alright, but definitely less than the play store, i presume people were nervous aout giving their paypal details to some random app even though I didn’t see the login details of course.

How about using amazon.com’s mobile payment integration?

https://payments.amazon.com/sdui/sdui/business?sn=devfps/mps

Here are some others after a google search:

ZooZ | Secure In-App Payment Solution
One of the more recognizable names
Their website now suggests users don’t even have to enter credit card details - just take a photo of their card (Android, and iOS coming soon).
Payment options available to users include credit cards, paypal and bank transfer etc. - but don’t seem to include Google Play payments.
So using this SDK would violate Google TOS - unless you use your free trial app to redirect to your APK on your website. But then you need to have users enable “Unknown Sources” in settings so the app can be installed from external APK (I am guessing). So a whole bunch of layers added to the process (each probably causing attrition in conversion ratio).
They pay to bank account u.s., u.k., australia etc. - I assume that includes other places to if they have ability to wire. Also have Payoneer payment etc. (who they call their partner - they may even issue the card themselves also).
Have seemingly simple integration code for iOS, Android and HTML5 (“3 line integration”).

https://www.avangate.com
https://www.braintreepayments.com/developers
Mobile Payments | SMS Billing | Text2Pay - Tap2Pay | Android In-App Payments

Papaya Mobile (chinese mobile app company) - has deals with Zong (China Mobile) and others.

Paypal has android SDK
This 2010 article suggests Paypal/Google deal may happen - but nothing happened so far it seems (at least on the developer being able to sell from all countries side).
Google, PayPal Set on Android Deal - TheStreet

A summary of alternatives - but there is no date on this article (so could be old):
https://www.x.com/developers/community/blogs/praveen/app-payments-android-apps

Ideally would be some way for developers in unsupported countries to signup with a company which would create Google Play accounts under their name or under their client’s name - and would receive the revenues and send them onwards to developers (with a 5% cut perhaps).

However, such companies would probably be under great scrutiny by Google - and get banned (esp. if one of the developers has a misbehaving app it could get the U.S. based reseller in hot water with Google).

So perhaps that’s why this has never gotten off the ground.

What is surprising is that Google is willing to sacrifice YEARS of exposure to developers (because it has taken them YEARS to not expand everywhere). This is surprising when Admob and others are perfectly happy sending revenue to those same developers. They could easily outsource their payment solutions to a Google-owned separate company (like they do with Admob) and have that available everywhere in the world to developers.

But they don’t. Why ?

It is perhaps not even that Google does not care - but there maybe some holy cows among the executives incharge of these divisions - who cannot be fired, but also are unable to do the drastic changes needed to get things done. That is, some Google execs may need to be fired to get things moving in this area.

That is, Google may have it’s own bureaucracy issues within the company - when they focus on some areas but not on others which are essential to the maintenance of their ecosystem (how do you grow without open access to developers).

As expected the situation will get worse - sure spam-based and all the wrong types of advertising will work for some apps, social games will still make a killing using in-app models, but the new blood will not be there for individual and new companies just starting out.

Essentially Google is losing touch with the entrepreneurial side of things.

The difference between Apple App Store and Android Google Play is that Apple had a history of payments with iTunes which they leveraged - so they have a basic revenue model in place with payments. The AppWalls and advertising as supposedly the business shifts from paid to in-app payments (and recurring payments as in social games etc.) is interesting - however I suspect for a whole class of app, the one-time payment model STILL works (has Apple done analysis on this ?).

On Android the payment model was non-existent because Google never pushed that earlier, the demographic was poorer or more worldwide without access to credit cards.

Now Google maybe placing it’s bets on the Android market scaling hugely (and covering for lower payouts per download for developers), or the much hyped recurring payments in social games - HOWEVER, it has a gaping hole for the payment models. That is, the appearance of successful social game stories DOES NOT compensate for the ABSENCE of a payment model for paid apps like tools apps etc.

So Google is ignoring a foundational aspect of it’s developer base - while being bedazzled by the media hype surrounding the recurrent in-app billing models.

Now one way one COULD compensate for this - and as I said GetJar etc. are just not going to cut it for extracting $5 type payments from users (that would be 50-100 app downloads required to earn that). And that may be with possibly adopting a pay-as-you-go model (though for tools apps this will rapidly get irritating to users - as said in an earlier post it is FAR easier for people to pay $5 for something than download 50 apps - and the paying $5 for tools category of user may not have the time to download 50 apps even though their kids might).

So one way this would work is for your app to show a “health meter” for your app - and user has to “feed” the app occasionally to keep it’s health above zero.

So they use your app - and require a single app download on GetJar (or such methods) - and this charges to full - and lasts maybe 10 days.

Since most users would be leaving your app and never coming back after 7 days - this allows you to charge them a small increment. Longer term users would be paying you continually (you could have the need for health rejuvenation stop - when your app achieves nirvana i.e. doesn’t have need for eating anymore - say after 10 such GetJar app downloads).

A variation on that may have user charge as many GetJar coins as they want (which inevitably they will go overboard if your app is good) - and that stays in the health meter for longer.

So anyway … maybe something like this will work.

HOWEVER, again here Google stumbles onto the path of developers by PREVENTING blocking of apps - though it seems free trial apps are ok (?) if they are advertised so ?

The apps that GetJar is now distributing - they will take your app and put a “pay to proceed” wrapper around your app - are clearly non-working apps - yet are surviving on Google Play.

So I think the lack of Google Play engagement (compare that to the effort done by Meg Whitman at Ebay in early days to get things working smoothly with buyers/sellers) - is that it has raised questions in the minds of developers about just how knee-jerk Google is with account disablements etc.

And I think that itself creates a “high risk” environment in which developers are operating - those who are willing to buy new accounts as a strategy may be immune to this - but it is terrorizing the average developer with fears of “unknown consequences” - because Google Play reps are not available to answer any and all questions - i.e. there is no free-for-all message board where some Google evangelists answer questions etc. (part of the reason they cannot do so is perhaps because Google relies excessively on “secret” recipes in their algorithms - so they probably fear their evangelists revealing things inadvertently to developers on such forums).

While it may seem all is ok for Google - but their lack of feedback to developers creates a “terror” environment (where the fears of account disablement, loss of livelihood with all apps associated with the account being disabled are being perceived as all likely possibilities).

While such stories are circulated by developers who may have truly been egregious in their behavior - however the impact of it is quite real. It keeps developers scared and unwilling to do anything remotely exceeding the Google ToS. However, it goes further when developers air stories of disablement without any evident violations that they could see.

That Google chooses to stay quiet when such info is traded between developers suggests that Google is secretly wanting to developer such notoriety of the “capricious axe that can fall at any time on developers’ heads”. This maybe enjoyable for Google execs reveling in the power this may give them, but it is not healthy for the long term development of the developer ecosystem.

What it will do is scare away the serious developers of tools and apps - while leaving the Google app environment open either to “I did this for free just for the enjoyment” crowd or the recurrent in-app billing for social games. Leaving a big gap for the “middle class” of apps.

In effect what Google is fostering is a scorched earth environment - similar to third world countries or like countries facing crisis - where there is no middle class and there is only the very rich, very willing to do anything top echelon.

Sure, this will work for the short run - but when the payment environment DOES gel for Android (or Android-like systems as under development in China), the payment environment may no longer be in the control of Google anymore.

I am gravitating towards one of two GetJar schemes:

  • have the app run as a free trial for a bit - when it expires there are AppWalls presented very heavily - to escape user just pays 100 coins (making it more than 100 coins maybe too much work for the user ?)

  • have the app run as a free trial for a bit - user then has option to pay an installment (could be just 10 coins) OR pay the full whatever is remaining of the 100 coin total payment. This way if they are overwhelmed by 100 coins (or 200 coins could make it higher) then they just pay 50 coins for now and know it goes towards their eventual purchase and they get to use the app. On screen they could see a progress bar in different colors for progress towards full payment and the time left in the currently running free trial (so every time they pay GetJar coins it gets them one step closer to full payment and it also gives them some time until next have to pay) - once total payments amount to 100 that unlocks the app completely.

This is a lot of nuisance to the user who in many cases would be willing to just pay $1 or $5 (for a good tool type app).

Any suggestions would be welcome.

Hey adforandroidapps,

If you are interested in publisher, we could make a contract with you, and publish your app in the market. The main part of contract would be 30% of income for publisher and 70% yours… If you like it and want to talk about conditions, contract, and etc… write here.

Thanks

Thanks for the offer - a bit steep - but thanks :slight_smile:

One would think there would be a healthy market for such reseller services (evidently even publishers would be scared of publishing as may get banned - but one would think that ad-less paid-only apps maybe worthwhile for such reselling).

For now I will include GetJar (though I don’t even know HOW one gets paid with GetJar - their website doesn’t even have a paid portal - just a webpage which lets you download .csv files for the payments - there is no portal for setting up wire transfer etc. etc. - and I haven’t earned enough from previous apps to bother - as I noted GetJar payments were a fraction of the ad revenue for earlier apps).

But I may still include GetJar - they may be many things but they don’t seem to be a corrupt company - and hope that a tool app which provides real value may push users to actually use the GetJar route.

One difference between publishing on iOS vs. Android is that on Android you can have a nickname for your “author” field that is seen by users. While on iOS App Store your REAL name gets put there (if you register as individual developer). If you don’t like that then you have to have a business name (sole proprietorship or such) whose name you can provide (even then from some web postings it seems your real name may be either posted in small letters or findable - not sure about that part).

I have yet to get a sense for how good the tools and documentation is and how fast of a ramp up it is to get proficient on iOS development.

Meanwhile I will also explore development on iOS - just got a used laptop and in fact developed the upcoming android app mentioned above mostly on this new mac - transition from windows to mac takes about a week or so to get used to it. While in other areas, macs may suffer in terms of running the same tools, but for android/iOS development (if you are going to dedicate to just that work) then the mac is good enough. Hope to do most of the work on the mac for android - don’t know how long it will take to get proficient on iOS.

I recall some folks here posted about iOS as well - any comments about how good/bad the “app discovery” issue was between Android and iOS.

That is, for all the positivism about iOS being better paying etc. it seems there are similar (or worse ?) issues on iOS App Store regarding app discoverability.

In addition App Store changes may have reduced the exposure for lower ranked apps.

So any insights into how well one may fare if they create a similar app on iOS ?

adforandroidapps, you write too much). Did you think about writing some book?

Also, why you dont give a try Tapjoy? I use them, and they have wire transfer and provide the same functionality as GetJar…so

Yes, it should be a suspense novel where the hero is making apps for a major corporation, where the axe is always ready to fall (corporation could ban the app any time) and there is nobody at the corporation when the hero calls. Sounds a bit like 1984 or Brazil (the movie).

Regarding Tapjoy - would you say that the revenue generated by Tapjoy is comparable to that from ads ?

Didnt get your question but lets say I will try to answer.

You are somewhere in the world and you can’t sell your app. So, you think to use coin-system to unlock some features in your app. And for some reason you want to use GetJAR, which doesnt have full documentation and you didnt even find a place for wire transfer…
So, I recommended to you Tapjoy, which also has coin-system, and users can install some of apps from your app->get coins->unlock some features in your app. And it has complete documentation, paypal+wire payment, and more then few years in this bussiness. So, why you should use GetJar?

Yes, Tapjoy seems more established and even more acceptable to users in the tests I have done (most people say they prefer the look of the Tapjoy offers). Yet I had some biases against the Tapjoy model of offers - while GetJar seemed relatively cleaner. GetJar was solely concerned with app downloads (and not offers etc.).

GetJar SDK was a pain to integrate as I have documented before - in addition they don’t seem to have the polish of some of the other ad networks.

But I will consider Tapjoy now.

My question was specifically - for those who have used Tapjoy - were they able to get comparable revenue from Tapjoy route as they were getting from ads etc. This is surely a very sloppy question since it depends on how well ads were implemented as well as how well Tapjoy etc. was implemented, but I ask this in a very ballpark way.

I think some folks here have commented that Tapjoy was reasonable source of revenue earlier (though that also seemed to wax and wane - like the performance of the ad networks) - and depending on whether “offers” were available for various locations etc.

By the way, I just noticed in re-reading the Tapjoy website docs of a very clear difference between Tapjoy and GetJar (related to recovering user status from their servers - which can be useful for recovering user state if they have done a “Clear Data” or reinstalled on a new phone). Tapjoy allows user’s current virtual currency balance to be stored on Tapjoy servers (so can be retreived for app later if user clears data etc.). GetJar does not currently allow such a use - rather they have managed products and unmanaged products i.e. the managed products are those which can be queried whether user has bought that feature or not. While unmanaged ones are that are “consumables” which can be consumed without keeping track of how many etc.

So slightly different. I think for the purposes of my app which I outlined above i.e. user keeps replenishing a currency reserve - it seems the Tapjoy approach would be better suited.

With GetJar it is also possible - but then the app has to remember it in terms of whether such and such products were bought and querying GetJar servers for that info.

Anyway, just saw this so thought it maybe of interest for folks.

If you don’t find a “legal” sdk to get in-app billing, you could let the users create an account for $5 on your website and then they have to log in in your app before using it.

Just an idea for a little more complicated workaround

I didnt understand very well your problem (to be honest I didnt fully read all your messages):

  1. You cant put IAP because your app’s focus is a single country, and that country doesnt have payment yet?
  2. Or you cant put IAP because you live in a country that Google cant pay to?

For 1), cant you target other countries which accept payment (almost any country)?

And for 2), cant you open a company in another country which accepts payment?

Hmm … as with most things mobile - every extra step erodes the conversion rate one would think.

However for an app which is essential or has really desperate users, one could do that I suppose.

Another option - don’t have info on that yet - could be to publish on amazon - so it is downloadable via Amazon app (not available on Google Play - user has to first download the Amazon app).

I can’t publish a paid app because Google Payments is not available yet at my location.

If Amazon is now doing a push to get all developers - I wonder if it could be a possibility to sell via Amazon App … ?

Part 2 is too complicated - the other country/tax issues etc. …

I integrated an app with the Nook in-app-billing framework about 3 months ago. Firstly forget about Nook for a potential marketplace as they’ve resigned from creating their own marketplace now really…

But, they used company called Fortumo to do the payments for them. Fortumo is a payment system / API for Android (and others I think) that you can use anywhere apart from Play and Amazon etc for obvious reasons, but it seems to be a payment solution that has plenty of billing options and seems to cover carrier billing in various countries quite well. On top of that, coding with the API was way easier than Google Play IAB so that was quite nice.

I’m also very interested in making sure I’m using the best in-app-billing solution I can find for non-Play/Amazon type marketplaces. I’d be very interested in opinions on Fortumo and alternatives.

So you are very positive on the non-Google Play markets as potential ? Do you expect like similar downloads from non-Google market as from Google ?