Google failing to pay Android developers Some Android developers aren't getting the money they should, with revenue from web-based sales never finding its way into their accounts because of a problem that's lasted months. The issue first surfaced at the end of last year, with a few developers noticing a mismatch between sales and receipts, but only some sales are …
This is all our own fault.
First raving on about Android and Google. You see what happens when you put your eggs in the wrong basket.
Should have stayed with Symbian. Especially since QT is also an easy platform to develop for. And that's what all these fart-developpers really care. Easy development, easy money.
The thing is that Android is becoming worse every time there's a new version. Not technically but programming-wise. First M$ demanding 5 bucks on every Android device (there goes the free market), then Oracle making trouble over the Dalvik-engine and now this.
What's next? Some fucking retard sueing Google because their devices have a power-button?
Time to leave folks.
Nope. Easy money is when you release products for a platform that has a lot of customers who are buying a lot of apps. From all accounts, that means iPhone, with Android in a distant second place, and Symbian and the rest not figuring in at all. Show me newspaper articles about Symbian app developers making millions because I haven't seen any.
Google REALLY doesn't like talking to people, do they.
I keep an eye on a shop that sells through Google Checkout, and some of the time, incoming orders will go through a 'Customer Review' at Google's discretion. While this review usually takes a couple of hours, recently it's started taking a day or more on some orders. Now usually the 2-48 hour delay isn't really a problem, except that Google puts on the customer's receipts "*Shop name* is responsible for charging and shipping your order. Have questions? Contact *shop name*", so when the transaction doesn't go through within 4.3 seconds, the customers come complaining, wanting to know why *we* haven't charged their order yet, and what *we* are going to do about it.
'Course we can't actually do anything about it, Google doesn't let us override the checks and charge the order, so all we can do is point the customers to the page on our site which was created with the sole purpose of showing them what the status of their orders is and why they shouldn't bother coming to complain to us that they haven't been completed.
Google simply doesn't want to bother talking to customers.
Sorry but really, its your choice to use google.
They really don't care about your business because if you leave there is still another suck ...er.. ready to come around and take your place.
You have the choice to walk away and use another commerce infrastructure provider, but you don't do that, instead you bitch about it.
My suggestion is to do both. Bitch and vote with your feet.
I'm with Mr Gumby here. There are many providers of online commerce systems; nearly all have better security, far better customer relations, and faster turnaround.
Google Checkout is cheap for a reason, but they're still not cheap enough to excused their half-assed product offering. The payment system might be easy to integrate, but that's Google all over: they only ever consider the developers, not the end users, and it's there that it really sucks: near nonexistent support and unpredictable clearing make it a bad choice for most businesses.
If this is your main business, you should be using proper tools.
Well, I don't see why you are criticizing this post. Anonymous raises a good point about dealing with Google Checkout. And I would generalize that, with a company that refuses to get on a phone, certain types of dealings are best avoided.
Would you rather no one knows there is a problem?
Personally, it's been years that I've refused to have anything to do with Paypal and I'm not any worse for it. But this decision was based on the complaints of receiving-end folks that have had bad experiences with them.
p.s. If you read the post, you'll also notice that ano states that he/she is looking after a site on someone else's behalf.
I'm sorry, but when a vendor screws me, the first thing I do is look for another vendor who can provide the service.
Being vocal is good, because it alerts others to the same problem and serves as a warning.
Now are you suggesting that there are no other options to using Google?
:-)
Oh and if you're looking after a site for a friend, then you should do the due diligence on their behalf and then make a recommendation to move. If they don't move, then its a good sign to stop 'looking after the site for your friend.'
Does the same thing happen to devs who use the Apple App Store?
We need to how the Chocolate Factory stands up against the 'fruit'.
could it be that Apple pay their devs properly? Can someone tell us?
I don't use an iPhone nor Android so I don't have a vested interest one way of the other.
Yeps, though Apple uses "another trick" to achieve this.
They suddenly decides that your app isn't good enough for the appstore and simply remove it themselves. They invent some regulations as an excuse and you get screwed.
Free market, remember >:->
God, I miss Maemo, Windows Mobile and Symbian/QT.
Where are the good old days that you search the web for some new wonders of palmtop-programming? The fun was in the search itself, the satisfaction if finding it and installing on your device. Damn, where's that Delorean... I wanna go back!
as long as sales cross a certain threshold. Otherwise they hang on to small sums.
Small sums times millions of developers equals non-trivial money - 'non-trivial' meaning the kind of sums most of us would be impressed by, but Apple considers a rounding error.
Apple could in theory pay even small sums monthly. It's not like they can't afford the transaction costs.
But they choose not to.
Otherwise - unless they take a dislike to your app and hold it in review or bar it from the store - payments seem reliable.
I don't do Android, so I don't know how frequency and throughput compare.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
