Google Payments API | Hacker News Reader

Google Payments API

developers.google.com

110 pointsemwa25 comments

Looks like Stripe supports it. The name is a bit different, but this is probably just Google being Google.

Android Pay, Google Pay, and Google Wallet (I think) are all pretty much synonymous.

I've been waiting on this since July, when we implemented Apple Pay at edX. They missed the advertised September deadline. Despite signing up for the mailing list, I have yet to be notified about the functionality. Now that I'm seeing all the press about it, there still seems to be no way to register as a merchant. This is quite disappointing.

Sounds very... Google-y. I love Google but I don't plan on wasting any of my time integrating with their tech anymore.

Before I get my hopes up.. Is this "only for US" (and a small number of countries)?

Under the section about the rules

> The following terms apply if you access or use the Google Payment APIs in Central America, South America or China: ...

I'm no lawyer but this seems to imply that it at least includes those regions.

It is a shame that there is no clear information regarding this. I am in Costa Rica (Central America) and would love to use this here.

Ultimately, acceptance depends on who is processing your payments (e.g. Stripe, Adyen, CyberSource). All Apple/Google Pay do is take advantage of tokenization, which allows buyers to send merchants a token/pointer to an account rather than a real credit card number. Every transaction gets a different card number to minimize risk in the event of a data breach. Additionally, both services make it really easy to checkout by providing a simple method to provide the billing/shipping address in addition to the payment info. No more typing. Just click the appropriate pay button, and confirm payment with your fingerprint/passcode on your phone.

Here is a demo I created for edX: https://www.youtube.com/watch?v=axTCbUjWcbI

Oh ok, thanks for the detailed explanation!

If the purchase is for digital goods, would it need to be for Google Play in-app billing, whereas if the payment is for physical goods, then it qualifies for Google Payments API?

What does a subscription for a membership for physical and digital goods fall under?

Thanks for the pointers.

This must be the 5th Google money API/interface to date. It doesn't seem like they learned from the previous attempts.

I haven't used Google's previous implementations, and I'm bummed I still can't use this one. I have high hopes for this implementation because it is written to comply with the W3C Payment Request API (https://www.w3.org/TR/payment-request/). Microsoft and Mozilla are also working on implementations. Apple Pay for Web follows a very similar API. As a developer who deals with payments this makes my life a lot easier as I can create a single implementation that enables users of almost every major browser to take advantage of speedy checkout.

I think this will substantially increase conversion rates. My experience with it as a customer was that I paid for something I otherwise wouldn't have, because I didn't have to input my credit card info.

I feel this all the time. Especially for flights, I will pay like $20 bucks extra if I can buy using Google Flights and don't have to go through the slowness, upselling, and credit card entry of the airline's site.

Do you fly for business or otherwise fly a bunch? I 0-3 times a year, typically for vacation, and I am extremely price sensitive. I'd gladly spend 5 minutes on the airline's website to save $20.

It all depends on how you integrate. I added Apple Pay to my site. Relative to PayPal, my conversion rate and AOV are higher. Relative to credit cards, only AOV is higher. In my case Apple Pay is a payment option on the checkout page. Apple and Etsy have a similar integration. Lululemon, on the other hand, puts the Apple Pay button right on the product page. Want some shorts? You can literally purchase them within seconds of having landed on the page!

Other factors that hamper wallet payments: - We didn't do any marketing around the rollout. Those who ended up on our checkout page and happened to be using Safari...and happened to have device with a fingerprint reader...and happened to have a credit card setup, saw the Apple Pay button. Others did not. A small marketing push might have helped attract those curious to try out the technology. - User input is still an issue. We still require users provided a billing address to help combat fraud. When I first created my billing address for Apple Pay, there was a typo in the country name. This resulted in an invalid country code being sent to my backend server, which rejected the request. The UI doesn't show the country at all, and I ultimately had to delete my own contact card to fix the address. - Not all banks support the technology. I've seen payments rejected from Russia, Australia, Canada, and even Georgia (U.S.) because some banks simply don't support tokenization/Apple Pay.

You can see some of our initial work at https://openedx.atlassian.net/wiki/spaces/LEARNER/pages/1615..., if you're curious.

How does this relate to Android Pay? Is Android Pay deprecated?

This is an implementation of the W3 Payment Request spec I believe: https://www.w3.org/TR/payment-request/

They talked about it at Google I/O earlier this year: https://www.youtube.com/watch?v=hU89pPBmhds

(I believe this is how it works, I could totally be wrong here, I haven't read on it too much).

This is a way of using forms of payments people have stored with Google (cards added for Play store, android pay, or other services) to pay for things with from merchants. The payments don't route through Google, rather it pulls the card details from Google and send them to whatever merchant you are buying from.

EDIT: This is useful: https://developers.google.com/payments/mobile-web-tutorial

It looks like websites can request data back as a Gateway_Token (to then run through Adyen, Stripe, Braintree, or Vantiv). Or you can setup a public/private pair[0] and Google will send the card details back of as an encrypted bundle that you can decrypt in a PCI compliant environment.

(disclaimer: I work on payments at Google, opinions are my own. I didn't work on this feature and don't really know anything about it).

[0] https://developers.google.com/payments/payment-data-cryptogr...

Does Google see the merchant you're paying?

See[0]. The "Pay With Google" initiative is adding a 'supportedMethods' of 'https://google.com/pay'. What is then in the data section of that supportMethods call to Google is up to Google, which is specified here[1]. It looks like Google required "merchantId", which the merchant registers with Google to get access to the cards Google has stored for that customer.

So yes, if a merchant wants to use a customer's card on-file with Google to pay at a merchant with "Pay with Google", Google will be able to connect the 2 dots together, but I'd read the ToS to see what is allowed[2].

The value-add here for merchants is to get customers to complete a purchase without having to go through the pain of typing in their card details. And for consumers, if they don't fully trust the website and the website is using Gateway Tokenization, then the merchant never sees the credit card data.

[0] https://www.w3.org/TR/payment-request/#the-methoddata-argume...

[1] https://developers.google.com/payments/mobile-web-tutorial#a...

[2] https://payments.developers.google.com/terms/sellertos

I've read through this several times and I'm still confused. How does this relate to the Payment Request API? Or Google Wallet or Android Pay?

I don't get. I really don't. I think I've looked everywhere but I can't find it. What's the pricing?

This is more low-level than that. This is an API to retrieve payment details, not to process an actual payment. You'll want to use Stripe or the like for that.

Thanks. So it's for people looking to build their own Stripe?

It is for app and web site developers that want to accept credit cards through the new Payment Request API. The backend would process the credit cards with their usual payment processor. The payment API is easier for users since Google remembers credit card details and they don't have to type them into a form.

Reply on news.ycombinator.com