Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google Payments API

developers.google.com

Post reply on HN
Print view View original

21–26 of 26 posts

Re: Google Payments API

#21

Post by ianburrell »

devdad wrote: post #18
untog wrote: post #17

Earlier quoted context omitted.

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.

Re: Google Payments API

#22

Post by clintonb »

thesimon wrote: post #8

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.

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

Re: Google Payments API

#23

Post by clintonb »

plumeria wrote: post #20
dopamean wrote: post #7

Earlier quoted context omitted.

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

Re: Google Payments API

#24

Post by clintonb »

arikr wrote: post #11

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.

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.

Re: Google Payments API

#25

Post by clintonb »

revelation wrote: post #9

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.

Re: Google Payments API

#26

Post by plumeria »

clintonb wrote: post #23
plumeria wrote: post #20

Earlier quoted context omitted.

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 checkou…

Oh ok, thanks for the detailed explanation!
Post reply on HN