Google In-App Payments for the web | Hacker News Reader

Google In-App Payments for the web

checkout.google.com

116 pointsabraham44 comments

> The country in which your Google Checkout account is registered is not supported at this time.

Come on! If you can handle Android Market payments for me, why not other payments?

Non U.S. residents can't sell apps on the Chrome Web Store yet either.

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.

Oh, look! Yet another U.S.-only payments solution :-(

I agree. Disappointed. Once again.

What's the best international recurring payment micro-payment solution out there?

Bitcoin! I used it to pay a Canadian and a bunch of people in the western Hampshire to do content work or translations for my site.

Not exactly the easiest thing to understand, but it is so easy to send money across the border and have it arrived in less than a few hours at most.

I meant, some sort of easy api, iframe, whatever I stick in my site to get recurring payments. There are so many.

Kout: We're working on an exciting implementation. Launching soon. http://www.kout.me

(Full obvious disclosure: I'm the co-founder)

When will you allow sellers from Malaysia, Indonesia and Singapore?

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.

That looks neat, can't wait.

http://quickpay.net/

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.

(Full disclosure: I am a co-founder of Willet )

Except your homepage says subscriptions are coming soon

Thanks for the heads up. Hot-fixing now.

Here is the documentation for GIAP: https://sites.google.com/site/inapppaymentsapi/home

Latest docs at http://code.google.com/apis/inapppayments/

It'd be nice if more information was available without having to create or sign in to an account.

Agreed -- the page is completely useless in explaining why I'd want to invest time into checking the service out.

Only Google can hide the page behind a log-in and still expect us to come back (precisely because they're Google).

Commence Lodsys lawsuit in 3...2...1...

Yes, please. Rain down the multi-colored legion upon their heads.

I'd like to know how I verify that an in-app payment is genuine, that the Google checkout dialog really is legitimate.

The same way you already tell if the Google checkout dialog is legitimate? HTTPS?

An in-app purchase doesn't show a URL.

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.

If you haven't made a purchase before, the payment method is listed as "Add credit card" (also without a URL) on your Android phone.

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?

Does anybody know in which countries in-app payments are supported?

Pretty sure the apple version of this already brought some lodsys lawsuits

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

Also, is there a support phone number anywhere?

Agreed about the email checkbox - I don't want anyone emailing a user I've spent time and money to get without me getting a cut.

Piggybacking their own bulk email lists on top is a no-no, even if it is part of the Google Checkout option, imho.

Then don't use it.

Would it be ok if you proxied the process for your users?

What if you created the Google Checkout account for them? could you act like a gate keeper for his e-wallet? is that possible/legal?

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.

Does anyone have the numbers/more info to hand? i.e. what are the charges.

"The only charge for using this API is a 5% fee per purchase."

https://sites.google.com/site/inapppaymentsapi/home

Anybody knows how much of this fee is pure profit for them? Sounds like an arbitrary number far from their actual costs

  > 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.

Does it work without JavaScript?

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).

Also this is still open for only development environment. Production environment is yet to release

Reply on news.ycombinator.com