Took about a year before us Canadians could sell Android apps, so I withheld my joy until I went through with the sign-up process. Oh my sadness, this is probably scheduled for a 2012 release for us.
We're aiming to do that from the start. We're not just limited to Google Checkout - though that's an option - so we'll try and give you access to a payment gateway that you can get on.
Sign up on Kout.me and we'll shoot you an email when we're ready!
Willet payments (http://getwillet.com ) is a similar product but has what I believe a better integration process and lower barriers to entry for both buyers and sellers. Willet supports in-app payments for one time purchases, subscriptions and repeatable purchases.
Ah, I hadn't noticed that if you were already logged-in and had already entered CC information, that it uses an iframe lightbox, which you're right, naturally does not show a URL.
But then, they won't be entering any CC information without being at Google's domain. You only enter CC information at checkout.google.com, and it initiates a popup to go there if you are either not logged-in or don't have a CC entered.
So, as an attacker, all they're doing is getting you (the naïve user) to click a button that looks like Google's button, and since they've already gotten you to click on a button to begin with (to initiate the transaction) they've already gotten any clickjacking exploit you need out of the user.
I'm a bit confused - this is about in-app purchases for the web. Are you saying that on Android, a web in-app purchase shows a lightbox for adding a credit card and does not temporarily redirect to Google?
Things I don't want:
1. Google branding my checkout process
2. Forcing MY users (who already created an account with me) to create a Google Checkout account.
3. Auto checking a "news and special offers" box to send my users email
Well, this was an honest question about proxying the creation of the needed accounts automatically from your app.
And wanted to know if this was permitted/legal.
You know, taking the credit card data from the user, storing it in your secure app, creating an email address within your app, submiting info provided by your user to Google Checkout and then when a payment needs to be done:
User needs money to pay something you are selling ->
Your app then goes onto the Google Checkout account of the customer and tries to get some money for you.
You basically are making your own API on top of the current Google Checkout. Maybe using scraping and stuff (just like how InDinero scrapes and get your bank data).
I'm asking because I cannot verify if this indeed can be done. I cannot create a Google Checkout account since I'm not from the USA.
> Anybody knows how much of this fee is pure profit for them?
> Sounds like an arbitrary number far from their actual costs
Before you begrudge Google for making a profit, perhaps you could elaborate on what you sell or plan to sell online and how much pure profit you intend to make.
Games virtual currency, in which the pure profit margin is very high. But i am not google / apple / facebook. I find the fees all of them incur to be out of touch with reality, and as more and more payment solutions become available i expect them to drop.
Tried to run the one demo on their info page and it was a mess. Had to complete a sandbox checkout registration form and then was thrown a bunch of errors.
I have high hopes for this (or something similar).
Come on! If you can handle Android Market payments for me, why not other payments?