
Google Payments API - emwa
https://developers.google.com/payments/
======
thesimon
[https://stripe.com/docs/pay-with-google](https://stripe.com/docs/pay-with-
google)

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

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

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

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

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

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

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

~~~
clintonb
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](https://www.youtube.com/watch?v=axTCbUjWcbI)

~~~
plumeria
Oh ok, thanks for the detailed explanation!

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

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

~~~
clintonb
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/](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.

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

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

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

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

~~~
kyrra
This is an implementation of the W3 Payment Request spec I believe:
[https://www.w3.org/TR/payment-request/](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](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](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...](https://developers.google.com/payments/payment-data-cryptography)

~~~
Larrikin
Does Google see the merchant you're paying?

~~~
kyrra
See[0]. The "Pay With Google" initiative is adding a 'supportedMethods' of
'[https://google.com/pay'](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...](https://www.w3.org/TR/payment-request/#the-methoddata-argument)

[1] [https://developers.google.com/payments/mobile-web-
tutorial#a...](https://developers.google.com/payments/mobile-web-tutorial#api-
parameter-list)

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

------
dbbk
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?

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

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

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

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

