Tip:
Highlight text to annotate it
X
GUS CLASS: Hello, and welcome to the Google+ developer
office hours.
I'm Gus Class, a developer advocate for the Google+
platform and I specialize in the publisher features, such
as the +1 button, Share, and now the history API.
Joining me is Jonathan.
He's on my team and is also a developer advocate.
Jonathan, want to give a little intro?
JONATHAN BEYER: Hey everybody, Jonathan Beyer here.
I'm the Google+ developer advocate for Hangouts.
GUS CLASS: Awesome.
So today, Jonathan will be talking a little bit about the
Google+ Hangout apps.
And specifically, he'll be talking about using the Google
Wallet API for payments within Hangouts apps.
This is real exciting, because it introduces a lot of new
scenarios for people who are interested in accepting
payments from Hangouts.
So Jonathan, want to get going with it?
JONATHAN BEYER: Yeah, sure.
So for those who don't know about the Google commerce APIs
and specifically payments, Google provides a really easy
to use e-commerce API to allow you to accept payments inside
your web apps.
And it's competitively priced [INAUDIBLE]
industry.
But the key thing about it is it's really easy to use.
And by really easy to use, I mean I had no idea how to use
it, and I got it working within an afternoon.
I actually just used the public documentation, and I
was able to accept payments within my Hangout app, which
is really awesome.
So I'm going to start with screen shares to walk you
through a few things.
Switch over.
Now, you should be seeing my screen.
Is that--
Gus, can you see it?
GUS CLASS: Yeah, I can see it.
Also Jonathan, I want to remind anyone who's watching
to ask any questions you have within the event, and we'll
try to get to them as we go along.
JONATHAN BEYER: Great.
So the homepage for the Google Wallet is
developers.google.com/commerce.
And there's the Digital Goods API which was formerly known
as the In-app Payments API, and that allows you to accept
payments within your application.
Now, all it really requires you do is to learn a little
bit of technology which I'll go over in a bit, and a simple
JavaScript API.
The piece that you've got to learn is a thing called JWT.
It's an acronym for JSON Web Tokens, and it's just an
encryption algorithm for transporting secure
JSON over the wire.
The fortunate thing is there's an array of libraries in
pretty much every programming language out there, so it was
really easy for me to get up and running.
And using a sample application that came with the developer
site that's hosted there, I was able to integrate that
pretty quickly.
So let me talk a short, brief minute about what JSON Web
Tokens are by going through the documentation.
And as it loads--
so a JSON Web Token is really an encrypted JSON file.
And the pieces to the JSON Web Token are some timestamp
information like when it's issued, an expiration date,
and then the actual items you are trying to sell.
What makes it a token or encrypted is your seller ID
and the seller secret that Google gives to you.
And then the library that you choose use wraps it up, and
then you call a simple JavaScript API.
And on this page you'll see the actual method is
[? payment.in-app.buy ?].
[? And ?]
you pass in the JWT and you start the purchase flow.
It's really that easy.
Now what I wanted to do, switching back to camera, I
want to make a very simple application that allows me to
buy something inside of a Hangout.
So to simplify--
[INAUDIBLE I wrote a simple App Engine project based off
of the sample project that whittles it
down to an AJAX service.
And I'm going to walk you through the AJAX service.
But the neat thing about the AJAX service is, I just pass
in the name, description, the price in the URL to that AJAX
request and it creates a purchase.
This is really good for debugging and testing.
Probably not something you want to use in production.
So switching to the actual code.
Can you see that OK, Gus?
GUS CLASS: Jonathan, you may want to make the font a little
bit bigger for the people looking because it's--
I'm having trouble actually maximizing this video for the
full screen.
JONATHAN BEYER: How about now?
Is it--
GUS CLASS: It looks lot better for me.
JONATHAN BEYER: OK, great.
So for anybody who's not used Python!
With App Engine before, this is a Python!
project, it is very simple.
The two things that you'll notice at the top is we
importing the JWT library and we're also importing from the
seller info file, my seller ID and seller secret.
I'm not going to show that to you, because then people can
start taking making money for me.
But there's a URL that we'll have in the show notes that
helps you generate your own seller ID and seller secret.
But outside of that, the process is really easy.
I have this route, this AJAX JWT route, that creates a
timestamp, assigns some default values for the name,
price, and description, and then encodes that information
into a JSON Web Token.
And you can see, it's just standard JSON with my seller
secret which tokenizes it.
And then, I do a [? response.out.right ?]
basically returning that JSON Web Token to the AJAX request.
A minor nit here, I'm adding CORS headers.
That allows me to do cross domain requests in most modern
browsers, and it works pretty reliably.
And that's in case you want to do something like a gadget
based Hangout app versus an iframe based gadget app.
Anyway, those are little addendums.
GUS CLASS: So Jonathan, to clarify, so those CORS headers
are used specifically for this scenario because you're using
cross domain scripting on here?
JONATHAN BEYER: Exactly.
We have a sample application that shows you how to serve
your hang-up from your own iframe.
If you do that, if you want to do AJAX from the same domain
to same domain, works no problem
even in legacy browsers.
If you're going to do something like a cross domain,
in a pure JavaScript environment, because it's
being hosted by Google, different domain from where
your AJAX is being hosted.
GUS CLASS: So basically this is AJAX being called from
within an iframe.
JONATHAN BEYER: Exactly.
GUS CLASS: Cool.
JONATHAN BEYER: I could have not done this with AJAX, I
could have done as a pure server-side application which
is probably the right way to do it in many scenarios.
And this is just for demonstration purposes and
flexibility.
GUS CLASS: Great, thanks.
JONATHAN BEYER: Now let's see.
What was the next thing I wanted to show?
Yes.
So now actually using that, let me switch back to the
screen share.
Switching back to the screen share, I have our Hangout app.
This is a web app version, so this will be iframe from my
app engine domain.
And for anybody's who's built a Hangout app before, you'll
recognize the hangouts.js In the iframe technique we have
to include an RPC library and then we include the Google
JavaScript API library, that's this one right here.
And that--
it'll be familiar if you things like maps and other
APIs that are JavaScript based.
Then from here on out, actually let me switch the
syntax over to make it a little bit more--
ah, there we go.
From here on out, we're just going to do a basic XHR
request, pass in the name description and price.
And here's where the actual payment happens.
On the response to that XHR I call the
goog.payments.inapp.buy.
And I pass in the data, which is the JSON Web Token.
And any success or failure, event handlers, they don't do
anything interesting right now.
But when all is good, this will start a purchase flow.
It happens in an iframe, within my application.
As a developer, I don't have to worry about anything that
happens here on out.
If there's a success, there's a success.
If there's a failure, there's a failure.
There's also a post back URL that once the purchase
happens, I can do additional logging.
The other thing that I skipped over that's important to note
as well, is that if you're using the Google payments API
for digital goods, you have to load the library
with that JSON API.
And I do a google.load.
This is all documented in the Getting Started Guide, but the
important thing to note here is I'm actually running in a
sandbox config.
So when I'm running in the sandbox config, it's a very
useful feature, because none of the credit card
transactions will actually really be charged.
So I can keep on testing, tweaking, and doing more
development without actually charging myself or doing $1.00
transactions which would be the case if we didn't have the
sandbox environment.
And when you're ready to go to production, you literally
change the package to production.
And now you can accept payments with
real credit card numbers.
GUS CLASS: Sorry, Jon.
JONATHAN BEYER: Oh, no worries.
Now that we've actually seen some of the code, I'm going to
try to see if I can do a screen share of that simple
app that's actually running today.
So let me screen share the Hangout, this might have a
hollow mirrors effect.
I don't know yet.
Let's see.
Can you see the application?
GUS CLASS: Yes.
If you zoom in a little bit.
JONATHAN BEYER: Yeah, yeah.
So name, description, price.
Those are the parameters that I was passing
into the AJAX request.
I'm selling a Slicer-Dicer which is the best salsa maker
on the planet.
This AJAX purchase is going to initiate the buy method.
And we'll see if that successfully loads.
So now from here on out, the developer doesn't have to
worry about anything.
This is the Google Wallet doing its thing.
I have a test credit card.
So you don't even have to use your own credit cards.
Google provides you with an AmEx, MasterCard
and a Visa, I think.
So in sandbox, you can keep on trying with that.
So it's completely, completely sandboxed.
Go ahead and press Buy.
The flow continues.
Make sure that my Wi-Fi isn't.
And guess what?
The purchase has just been successful.
And I'll probably see a success method if I look in
the console.
I don't know if you can see the console, but payment was
successful.
There's some weirdness going on with the Hangout, so at
this point--
GUS CLASS: So Jonathan, to clarify what's going on here,
you've got a sandbox account for Google Wallet as well as
for the Hangout.
And so all of these transactions that you are
doing are just nulls?
JONATHAN BEYER: Exactly, exactly.
And so it actually gets recorded in the sandbox log,
so you can see what's being transpiring.
But there's no real money being charged or any fees
being levied.
So you keep on testing in sandbox.
And once you go to production, you might want to have a bill
that is the production bill, that takes currency and then
in your dev environment, keep that sandbox built for
additional testing, and purchases,
and things like that.
GUS CLASS: Cool.
So if you wanted other people to test inside of your
sandbox, what would they have to do?
Would you be able to share out your app like you would any
others sandbox app and then--
JONATHAN BEYER: Exactly.
If I send this to you, Gus, you can go ahead
and purchase that.
I'd recommend you using a test credit card, but--
GUS CLASS: OK.
JONATHAN BEYER: --of course it's in the sandbox, so even a
production one won't be charged.
But as long as you have access to my application,
you can test this.
So it's really neat for other developers when they are
working together or if you're doing Q&A.
GUS CLASS: Great, thanks.
JONATHAN BEYER: Yeah, I think that covers it.
And you saw that code was pretty straightforward.
The documentation was super helpful.
We'll provide in the show notes links to the sample
code, because we'll be publishing this probably
tomorrow morning with the App Engine project.
[INAUDIBLE] credit cards, how to get your cell information,
and of course, the commerce application, the digital goods
application is already up, and a link to all that afterwards.
GUS CLASS: Great.
So what we are seeing is a real simple example of how to
use Google Wallet APIs from within a Hangout app.
And so Jonathan, we'll make sure that we include the link
to the sample code with the video so that people can
download it, play with it, experiment.
And then we'll have a little starter project for other
developers out there.
JONATHAN BEYER: Thank you.
GUS CLASS: So I guess what would be interesting now would
be if anyone has any questions, make sure that you
ask them in the event, and we're monitoring that.
And so Allen just asked, are there any best practices for
determining what products a person has purchased to make
them available in Hangout apps?
JONATHAN BEYER: So let me think
more about that question.
There's a--
I skipped over the JWT pretty quickly, but let's see if I
can go back to it.
There's is a section in that JWT that's called seller data.
GUS CLASS: So could you move that--
can you actually expand it a little bit more?
We're having trouble seeing it.
JONATHAN BEYER: Let me know if this is good.
Looks good?
GUS CLASS: Maybe a little bit bigger?
JONATHAN BEYER: OK.
It's not very interesting what I'm trying to show you, but
there's a field called seller data.
And that's one of the attributes on the JSON that
gets encoded in the JWT.
And that's where you want to put some additional tracking
information.
So if you are trying to figure out what part of your
application it's being come from, let's say you have
different applications, both in a Hangout and on the web,
you'd probably want to stick that in there so that purchase
gets tied to whatever that metadata is there.
In terms of figuring out what to sell, you probably want to
think about creating your own recommendation engine.
There are, of course, plenty of e-commerce solutions for
recommending products.
Your mileage may vary, I know a bunch that I could
recommend, because I've worked with a lot of them.
But to figure out what to sell is going to become the bread
and butter of your application engine.
GUS CLASS: Thanks, Jonathan.
So also, what are the types of scenarios
that we really expect?
Or what are people really been excited about doing with
in-app payments?
JONATHAN BEYER: That's a great question.
So the traditional I'm buying something within an
application makes sense.
Think about games, power-ups, levels, customization for your
characters.
Those are pretty obvious.
If you think of buying new games within games.
So if you have casual games like checkers or chess, and if
you want to buy a Chinese backgammon or something like
that, that's also totally within the realms of what
in-app payments do.
But other scenarios which are pretty interesting, if you
want to do something like a freemium model where you can
provide a level of your service.
So if it's not even a game, let's say it's for an activity
app and you want to say oh, one gig of storage is free.
Additional storage you can use in-app payments to buy that as
a one time fee.
But the other piece that we didn't go over is the
introduction of subscription billing.
So I believe at Google I/O, we announced the ability to do
subscription-based billing.
So if you're doing a service, maybe you're doing a
subscription for lessons inside of a Hangout.
So something like a cooking class or education where they
load the application.
Before they can start, you check whether they have a
subscription.
Otherwise you do some sort of prompt to subscribe.
That's really interesting and I think people will definitely
start exploring that as soon as they can.
GUS CLASS: Cool, that's pretty exciting.
I guess another question would be-- so we talked a little bit
about best practices.
What about security considerations?
How do we know that the information that's being
shared within the Hangout because it's a JavaScript app
in an iframe, right?
How do we know that the various
credentials are secure?
And what are some of the key security measures that are
being demonstrated in this sample?
JONATHAN BEYER: That's also a great question.
The JSON Web Token is core to what's making in-app payments,
or digital goods rather, secure.
Because it is using a seller secret and hashing that JSON,
it's hard to decrypt it.
There's also time stamps within the JSON Web Token, so
when it was created and when it expires which is persistent
on the server side, so it validates that as well by
making it moot if somebody tries to figure it out after
it's expired.
And the communications is done over HTTPS.
So even if you're using a non-Hangout app and it's over
HTTP, the purchase is in an iframe and it is secured.
So we do our best attempt to making it a fool-proof system.
But you can rest assured that there's all the industry
controls around making a secure payment system.
We fall into those.
GUS CLASS: Great, thank you, Jonathan.
Allen has a question.
And he's asking, in the context of items to be
purchased and used inside of the Hangout itself--
let's say that he has a game inside a Hangout, what's the
best way to determine--
actually it looks like--
what's the best way to determine what items they have
purchased, and then if they want to use them in a game
later, what's the way to synchronize across that?
What he suggested is using the user's ID, storing it on the
server, and then using that to look up which items they own,
and then bringing it back later.
JONATHAN BEYER: You took the words right out of my mouth.
GUS CLASS: OK, cool.
JONATHAN BEYER: In the context of a Hangout, we've talked
about this in former Hangout office hours, about there's a
Google+ ID, there's a Hangout ID, and then there's the
participant ID.
They're all different, they're all unique.
In the context of this, the most absolute, unique way of
identifying the user on Google+ inside of a Hangout is
to use the Google+, their ID.
That's on the long URL when you go to their profile.
Go ahead, use that as the key.
That's guaranteed and secure, and we're not going to be
changing that.
So that's valid.
And App Engine has a great back end for doing large types
of tables and big query for big queries.
So if you have a huge application, you can easy
troll through all those by looking at the item ID
compared to a user ID.
That's the right way.
GUS CLASS: Cool, great.
Thanks for that suggestion.
And I guess we're--
I'm not seeing any questions right now.
We'll hang out a little bit longer.
Jonathan, if you could talk for a moment about scenarios
other than games, specifically--
people are interested in doing things like accepting
donations through Hangouts.
And also about pay per view content.
So, featured speakers and so forth.
JONATHAN BEYER: Yeah.
So donations work the same way as in-app payment.
We don't have a particular API dedicated to donations.
But as you can imagine, because our split with the
developers is so fair, it's better than a lot of the
donation services out there.
So you would treat that as, I want to donate $5 to this
cause, you would do that with the digital goods.
In terms of non-game scenarios, I think the
freemium model is the right place to talk about this,
especially when you're talking about productivity software.
So if I have one user in the system, or five users in the
system that's free, if it's a combine board, or a
[? sprint ?] planning board, and if I add additional users,
I have to buy additional seats.
You can do that as a one-time purchase, or you can do that
as recurring billing.
And then if you want to piecemeal your product, so I
have something where you can use just the [? sprintboard ?]
for free, but if you want to have real time chat with
logging, you have to pay an additional $100 a year, or
something like that.
That's also a great scenario to do that.
I think the premium content is very interesting, and I
definitely like that model, because you have full control
of the application that's running in the Hangout.
And for somebody to do a paywall, or subscription-based
content viewing, the app lets you have full
control over that.
The digital goods make it accessible and monetizable.
The one area that it gets tricky is if you want to do
that over Hangouts on Air.
Because the Hangouts on Air is not restricted to the app.
The Hangouts on Air can run on youtube.com, it can run on
Google+ Stream, and it can run anywhere you embed that
YouTube feed.
So if you're looking to control streaming content or
even just static content on an HOA setting, then you're going
to-- you can't use digital goods.
Now, you can prevent that functionality.
So within our API, you can detect if somebody's
broadcasting, and that's something that we'll be
exploring further to make that even easier.
And then you could say hey, you're broadcasting this
premium content.
We're going to stop the feed until you stop
the Hangouts on Air.
And that's probably the best solution for anybody who's
looking to do premium content in a Hangout using digital
goods to monetize it.
GUS CLASS: Cool.
So another question has come up.
What if you have a limited set of products?
So let's say you've got a special edition item, and
it'll be sold from within a Hangout until
there's zero left.
You start with 10, and it decrements.
Is this possible using the Wallet API, or would you have
to use your own implementation on the back end?
JONATHAN BEYER: So inventory management is not done by
Google Wallet.
The payments API is the quick and easy way to make
purchases, purchases and subscriptions.
For doing inventory, you're going to have to build
industry system or look towards other systems that are
out there for inventory.
Your simple scenario, you wouldn't need a full
e-commerce back end.
I worked with a bunch of them in the past.
Sometimes they're overhead that you don't need.
If you want to have 10 items or X items and to decrement
them, I would do a simple App Engine project.
Have one of our data store, or even big query, depending on
what you're looking at, and then use something like AJAX
to decrement each purchase.
It's actually a very easy code, but the Wallet won't do
that for you.
GUS CLASS: So you won't get the transaction APIs for that,
just from Wallet.
So there's another question, and I really wish we had one
of the Wallet guys here, because they'd totally be able
to cover this stuff.
But would you happen to know what the limits are?
What's the minimum and maximum for Wallet API payments?
JONATHAN BEYER: So is that price?
Or is that--
GUS CLASS: Is it, I mean, can you say--
I know that particularly in app stores you will see the
minimum payment is like $1.
JONATHAN BEYER: Um hmm.
I don't know off the top my head.
There is--
I can talk to you a little bit about the pricing model
because we actually introduced a new pricing model at I/O.
It's pretty favorable for developers.
So when in-app payments launched last year or so, we
had a flat 5% fee across whatever your transaction was
which is very competitive compared to other products,
which made it very desirable.
Recently, we introduced a secondary structure which is,
I want to say, $0.30 plus 1.9% off the total purchase.
And the beauty of--
GUS CLASS: Whoa, what just happened?
JONATHAN BEYER: --as long as it's a measurable amount.
But yeah, we'll have to follow up with the Payments guys to
figure that one out.
GUS CLASS: Cool.
So it looks like we're not seeing too many more
questions right now.
We'll wait a minute or two.
We had some minor technical difficulties just recently
with the Hangout, but we should be good.
JONATHAN BEYER: Well, Gus, let me ask you question.
GUS CLASS: Yeah?
JONATHAN BEYER: You've asked me so many.
What's the first use that you want to see
with digital goods?
GUS CLASS: I mean, certainly something that is really fun
is the notion of real money within games.
I think it'd be interesting to see things like actual item
purchases and other exciting things for people who are
actually creating games.
I would really expect that to be the first and most critical
use of payments within apps.
JONATHAN BEYER: Yeah, definitely.
We have a strong user base of developers who are interested
in games in Hangouts.
It's obvious why there's a happy marriage there.
It's social, it's real time, it's fun.
And I think we're going to see a lot of adoption from the
games folks, bringing their Hangout games, making it
monetizable.
GUS CLASS: I think it also is going to mean more people
looking at that Hangouts API and looking at Hangouts for
the kinds of games that they can create.
JONATHAN BEYER: Yeah, definitely.
And it's not just game developers, it's not just
productivity and traditional app developers that we'll
going to get interest from.
Brands, and marketing companies, and agencies are
all saying, hey, this is a great opportunity to build an
interactive art piece or web app that brands can actually
get in front of the eyeballs of their consumers.
And then of course, if you have a monetizable piece to
that, that's awesome, right?
It's really hard to get ROI in a marketing campaign.
But if you build a Hangout app, which it's pretty easy to
do, make it fun and compelling, people
could pony up for it.
GUS CLASS: Yep, and we've definitely heard some success
stories about charities with getting really good engagement
from within Hangouts.
And maybe supporting a donation model within their
Hangout apps and stuff could give them direct revenue from
within apps.
So that's a cool scenario for sure.
JONATHAN BEYER: Yeah, definitely.
And there's a lot of traditional Hangouts that are
high-profile, low-profile, crazy things going on in
Hangouts that can be enhanced with use of Hangout apps.
What was the one I saw recently?
There was LA Robotics Club was doing a hack-a-thon
just the other day.
Maybe the thing's still going on today, and people were
building together and hacking and building crazy robots.
But now imagine if you could somehow turn that around and
do a hack for good kind of experience.
It's not necessarily a application or a game that you
engage with, but maybe you donate to a particular team so
that they can get more stuff.
And part of that revenue goes to a foundation.
Or whoever wins gets a pot and, the remainder goes to the
foundation.
So this is not a web app, this is not a game, but this is
using Hangouts to connect people and also the digital
goods to bring monetization opportunities.
GUS CLASS: Great, so looks like the conversation has
quieted down a bit.
And I think we're about ready to wrap up, Jonathan.
Thanks, everyone, for watching.
It's been a fun Hangout today, and keep an eye out for
Google+ office hours in the future.
Jonathan, Anything left to say?
JONATHAN BEYER: Just thanks a lot.
If you have any questions about Hangouts or Hangout
apps, or even digital goods, feel free to
+Mention us on Google+.
And of course, we can connect you if you have further
questions about the commerce APIs.
GUS CLASS: Great.
Thanks, everyone.
Have a good week, and join us again for office hours,
probably next week.
[MUSIC PLAYING]