Google I/O 2011: Introducing In-App Payments for the Web


Uploaded by GoogleDevelopers on 12.05.2011

Transcript:

AMIT FULAY: Good afternoon, and welcome to the session.
I hope a lot of you got a chance to see the keynote in
the morning where we announced this product.
And I'm really excited you could be here as we take a
deeper dive into what we've built.
Some housekeeping details before we get started.
There's a session feedback link, hash tags, and a video
recording of the session will be on YouTube 24 hours.
In the next forty five minutes,
we've got a great agenda.
I want to start with talking about why you should even care
about in-app payments.
Then we'll talk about what our offering is, both in terms of
the user experience and the API.
And we'll talk about how you can start implementing this in
your apps as you leave this room.
But let's start with introductions.
Now, throughout the blogosphere, there's always a
lot of speculation about what happens to start-ups once
they've been acquired by a large company.
Most of the team that built this product started their
journey in a very similar way.
We came from an acquisition that Goggle did in August
2010, a small start-up called Jambool with a product Social
Gold that helped developers monetize from within their
applications.
And we're really happy to be here in a short span of time
having built this product at of Google scale.
My name is Amit Fulay.
I'm a product manager on the team, and I'll be joined by
Mikhail and Luke, engineers who helped build this product.
The web has evolved, and so has the way all of us make
money on it.
In its infancy, web was all about selling physical goods
and accepting payments.
Developers built front ends to their existing stores, took
payments, and shipped the goods.
Then we saw a transition where not only were they selling,
they were actually advertising these goods on the web.
Search ads, display ads, this was all possible because of
the introduction of really sophisticated ad platforms
that could target and reach users in a
very precise manner.
We saw a lot of publishers build engaging websites,
attract eyeballs, and hence make money through ads.
Now, over the last few years we've seen another interesting
model come about, selling virtual goods
from within an app.
This has been led by the social and the
casual gaming space.
Some estimates put this to be a $15 billion market by 2012.
So we've seen a lot of different waves come ashore,
starting with what I call as the shopping wave, all about
E-commerce, B2B, B2C models.
Then supplemented with an ad wave that was all about
building audiences and making money through advertising.
And then the third wave is what I'd refer to as the micro
transaction wave. We've seen increasingly users embrace a
model where they're willing to shell out 99 cents, 79 cents,
for a song, for a tractor in a farm, for ringtones, for apps,
for rentals.
And that's a model that really is something new.

Let's look at another interesting trend on the web.
We all live on increasingly social and connected web.
At the end of 2001, there were 10 billion accounts that were
created on social networking sites, online worlds and MMOs.
And astonishing, half of those accounts were still active.

There's a reason a lot of us here are willing to pay four
bucks for a cup of latte.
It's not because of the coffee.
It's the experience of walking up to the store, listening to
that music, seeing the barista brew a fresh cup of coffee.
That's what we are paying for.
It's the same reason a couple of years ago huge number of
users lined up in lines for hours to watch the latest
movie, Avatar.
It was the 3D glasses, the IMAX cinematic experience.
That's what stood out.
They were willing to pay a premium in that case with
their time in order to get that experience.
And we are beginning to see a similar transition happen in
the online space.
It's no longer a web where you go and click on some links.
Users want to be absorbed, engaged in the web apps.
They decorate their profiles, create playlists, upload
pictures, create mashups, share with their friends,
build their farms for hours, build chocolates in games.
It's the experience that's driving them there.
It's no longer only about utility.
So when we look at a confluence of these trends, a
microtransactions model that's being embraced by both sellers
as well as buyers, an increasingly connected and
social web, and a user who is inclined to pay a higher price
for experiences.
When you combine that, that's a huge opportunity for all you
developers.
And in order to help you capitalize on that opportunity
we introduced the Google in-app payments for the web.
Now let's look at what this platform has, and what this
ecosystem would look like.
But before I do that, here's some more specifics about
we're announcing.
All U.S. developers will be able to leave this
room and sign up.
There is the flash version of the API that we will be
releasing in a few weeks from now.
And our plan is to go live this summer.
Now there's a reason we are staging this launch starting
with the developers first. First, we want to give you
some time to help integrate and prep your apps.
And we want your feedback in order to iron out anything
that's missing in this payments platform.
So our hope is we can work together, build some really
cool, engaging apps that we can get in
the hands of consumers.

What does this new web app ecosystem look like?
At the top is the application layer.
That's where all you developers come in.
You build engaging innovative apps, whether it's in
productivity, publishing, gaming, entertainment.
And you can find a distribution channel for these
apps through a web store, like the Chrome web store, or
through even your own websites.
All of these can be powered by the in-apps payments platform.

What have we built?
At the very core is the huge Google payments
infrastructure.
This includes things like fraud and risk management that
we don't necessarily want you people to worry about.
That's something we have a devoted team looking at each
and every day.
We have state of the art compliance, whether it's in
the U.S. or internationally, that meets all the regulations
in the way we store our credit cards, the way we do audit,
where we log data.
And analytics that can help you get insights into how your
users are converting.
Where do they drop off?
What time of the day are the most purchases in your apps?
Things like that which will be critical as you fine tune your
monetization engine.
Now, couple this payments platform with a
large, active user base.
Any user who has bought an app on Android market, bought an
e-book on our Google e-book store, paid for extra storage
in Picasa, bought extra minutes on Google Voice, all
of these users have created accounts.
And you are bringing all of this huge payments
infrastructure and a large user base into your app with a
simple API.
Literally it's one call to initiate payments and one call
to collect it.
And Mikhail will jump into what that API looks like later
in the session so that you know how to integrate.
But that's really what we think is the
beauty of this platform.
One API that in a way hides away all of the payments
complexity from you and delivers to you a large
transacting user base from Google.
And what your users who are buying apps or playing with
these apps see is a very frictionless UX.
Again, we'll see a demo of that today.
The whole goal is simple.
Payments should get out of the way as soon as possible.
Minimal steps, enter your credentials, pay, and get back
to the app.
And the best part about the user base is if they've
already paid they don't have to enter credentials again.
It becomes single click.

Now, a lot of you have tweeted about this.
A lot of web apps charge 30% for payments, which we find a
little ridiculous.
It's almost become a default, and we are not ever happy with
what the default is.
So in the morning, you saw in the keynote, we unveiled a
flat pricing structure 5%.

Now, I want to emphasize there's no fine print here.
This is not a pharmaceutical ad.
This 5% means you can price your items at 25 cents, and
because there's no fixed fee, you're never paying an
exorbitant amount from what you get.
You can price your items at whatever price points you like
or your users like.
The second thing I want to emphasize it this price point
is not only applicable on Chrome web store, but on the
entire web.
So if you build an app and you launch it on your own website,
you can integrate with Google in-app and the pricing will
still be the same.
So that's what we're offering, A flat 5% pricing structure,
simple API, and a simple UX.
Now to jump into the user experience, I want invite on
stage Jake from PopCap one of our early adopters, who have a
game Plants Versus Zombies some of you might know, that
integrated with this platform.
You saw Angry Birds in the morning, time for Plants
Versus Zombies now.
Hey, Jake.

JACOB MCMAHON: I'm going to give you you a demo of the
in-app purchasing, but since it's frictionless it's a
pretty quick demo, so I'll give you a little run down of
PopCap first. Our mission is to make fun games for
everyone, everywhere.
Our first game, Bejeweled, is a good example of that.
We released it about 10 years ago, and we've released that
game on over 15 different platforms now.
And for each platform that we release it on we customize it
for that platform so that the users, that's the first time
they've ever played that game, they feel like that game was
built for that platform.

We have six franchises, major franchises.
Plants Versus Zombies is the most recent one.
And that's actually what we're going to do the demo with is
we've got a trial version up on the Chrome web store, and
so what we've done is we've added some additional
content onto it.
If you're never played Plants Versus Zombies before, there's
two sides plants, zombies.
There's about 40 plants and about 25 zombies, and we've
got some additional zombies that the player can add
through microtransaction payments.
Now, jumping into the numbers, if you look across all of our
products we've got about 60, more than 60 monthly active
users that are playing our games.
If we look just at Bejeweled, we've got over 2 billion games
played each month.
And if we look at just micro transactions we've got over 3
million transactions a month at an
average cost of 75 cents.
Now, we've seen this business grow quite a bit just in the
last eight months.
It's grown more than 100%, to more than $2.5 million a
month, and now accounts for about 10% of our revenue.
One other number for you, 75% of our purchases are
re-orders, and that's something that were very proud
of because that's telling us that the users are trying our
game and they're enjoying it and they're coming back.
And that's where we want to focus is we want to focus on
making those great experiences that players really enjoy.
Plants Versus Zombies, as an example, we spent three years
making that game.
We spent a lot of time picking the right combination of
plants and zombies and trying to create a balanced
experience.
So as we add new zombies to that game we want to make sure
that that supports the old game play, as well as enhances
and evolves the game into a new direction.
So we've got three new zombies for this demo.
We've got a zombie in long johns, we've got a
hairy-chested, spandex zombie, and a naked zombie.
All right so let's switch over to the demo.
All right so this is the trial version that's available up on
the Chrome web store, and we did a mock up with it.

And we added a button so that we can purchase in it.
We just called it the Google Mart.
And in there we've got our three choices, spandex,
underwear, naked.
I think we should go well full monty, go fully naked.
So the user experience is what you'd want.
It's frictionless.
It's just two clicks to go through the purchase sequence.
We got the API about a week ago and mocked this up.
It was really easy to use, quick to implement.
Maybe I didn't get it there.

There we go.
We'll see what happens.
It was quick to implement, easy to use, which is exactly
what you would want.

Complete that purchase.

And here we go.
We will end up with our naked zombie that we can then play
in the game, and so fantastic experience.

So I'll hand it over to Mikhail to
talk through the details.

MIKHAIL SEREGINE: Thank you.
Thank you, Jake.

Let me slip back over here.

Great So I''ll tell you guys about the
API that we've built.
And as Amit has alluded to earlier, we wanted to solve
two major problems, first one is the buyer experience.
We want it to be very smooth so that people don't have any
trouble making one purchase after another, and they don't
feel like it's an obstacle for them as they're playing a game
or using your web app.
And the second, of course, is that we wanted to make the API
very easy for you to use so it's not an obstacle for you
to build this in so you can integrate quickly
and get paid sooner.
It turns out that these problems are related and so
when you build a [UNINTELLIGIBLE]
you want it to model the buyer experience.
So really to make some sort of API you just need to
understand how the purchase works.
And you've already seen that.
So just to review the structure, let's say you have
a web application where you can buy a star.
There's a buy button.
The buyer clicks on that buy button.
It brings up the payment screen you saw earlier.
The buyer just has to either confirm the purchase or enter
the billing details if they haven't already.
Payment gets processed, they close the window, and they're
back in the application and they have the item immediately
that they just purchased.
So to implement this API in your application you just need
to worry about two calls.
The first call will open the payment screen, on the second
call will accept the notification once the payment
is complete.
So that same diagram in terms of the API, the click
corresponds to the API call.
When a buyer clicks on a buy button the API call is made.
And then the notification corresponds to
the end of the purchase.
So the notification is actually sent to you when the
purchase is complete, but before the buyer has closed
that window.
So once the buyer has closed that window it's guaranteed
that the purchase notification has already been sent to you.
We think that makes it a lot simpler for you to handle that
end of the picture flow, and gives you fewer corner cases
to worry about.

Let's talk about, actually before I go on I should say
one more thing.
I've been using the example of a buy button, but that's
really not necessarily the only way to
implement this API.
The API call is just a JavaScript [UNINTELLIGIBLE]
call, so you can trigger it on anything.
For example, if you have another game and the user
completes all the levels you can immediately bring up the
payment screen so they can buy more levels without them
having to click anything.

Before you start writing code to integrate this API, you'll
need to do a bit to set up.
You'll need to create a seller account if you
don't have one already.
And then you'll need to grab a seller ID and a secret and
you'll use those to call our API to tell us who you are.
You'll also configure a closed back URL.
That's the URL where we'll send those notifications once
the payment is complete.
Let's talk about that first call to
open the payment screen.
As a web application you have a client side
and a server side.
The call starts on the server side where you use your secret
key to find the parameters of the purchase
that are being generated.
So you'll define the purchase.
You'll sign them with your secret key.
That will produce a token which is an encoded string.
You'll embed it in your web application source code, and
that'll get passed into our JavaScript library.
Here's the actual code.
This is Ruby, but it would look pretty
similar in most languages.
So you define the purchase.
It's very simple to define.
You just tell us what's being purchased, how much it costs,
and then you tell us who you are when
you're calling the API.
Yet So that's that the first code snippet.
The line at the bottom is where you use your secret key
to sign it and generate the token.
That JWT.encode call is a standard library.
All you need to know is you don't need to worry about
implementing the signature algorithm yourself.
And Luke will tell you more about that library we chose.

Now, you've generated that token on the server side, and
this is the client side.
First you'll include our JavaScript library, that's the
first code snippet.
Really you just copy and paste that and you're done.
The second code snippet actually
triggers the call here.
We've set up a buy button with an on-click handler that calls
JavaScript function in our library, and passes that item
token those generated on the server side
into the library call.

So after you've done that, the payment processing all happens
on our side.
The payment screen opens.
We interact with the buyer to get
confirmation or billing details.
And once the payment is done we process it on our servers.
We send you a server to server notification.
It goes to that URL you've configured earlier.
The details of that notification will include many
of the same things you put into the original JavaScript
library call, including the item description of what's
being purchased, the price, and when
that purchase happened.
We'll also include an order ID for you.
You'll be able to use that later to
reference this purchase.
And importantly you will need to echo that
order ID back to us.
That way we know that you received our notification, you
were able to decode our token, and got the order ID out of it
so we know that the user can reasonably expect to have the
item at that point because you've found
out about the purchase.
And at that point we're done.
The purchase has been delivered to you.
This is the code to implement that notification handler.
Again, this is a rails controller action.
This function gets called when your server
gets a post from us.
It pulls the first line.
You see it pulls the JWT parameter, that token, out of
the post parameters.
It decodes it using that same standard
library I mentioned earlier.
You call from application specific logic to give the
item to the user.
And then you acknowledge the receipt of that post back to
us by returning a status of 200 and the order ID in the
body of the response.
If anything goes wrong, you can just give us different
code as a response, like a 400 and then we'll understand that
you couldn't deliver the item to the user and so we'll
cancel the order.
That way the user doesn't pay for something
they couldn't receive.

Now, you might have noticed that the server to server
notification comes to your servers, but the user is
probably using the client.
So how will that item be actually
delivered to the user?
Of course there's several ways to go about it.
The simplest way to do it is polling.
So your client could poll the server side and wait for the
notification to come through.
But we can do better than that, and so we provide an
optional mechanism for you to use so you can pass an
optional call back into that JavaScript library call when
you start the purchase.
These call back functions get invoked when the purchase
either succeeds or fails.
And at that point you know your server has also been
notified, so when the call that is called on the client
you can check with your own server to see if you got the
notification instead of having pull it all the time.
Of course you do still have to check with the server.
The JavaScript call back itself is not enough.
The reason is any buyer with Firebug installed or a similar
tool can go and invoke that call back on themselves and
give themselves free stuff, naked zombies to
their heart's content.

And so that's why you want to check with the server to make
sure that the purchase actually did take place.
So let's review the whole picture.
Your servers will define a purchase, generate a token to
represent it, and pass it into the client.
When a buyer clicks on that buy button the token will get
tossed into our JavaScript library.
It will open the payment screen.
The payment screen will talk to our servers, complete the
purchase and you'll get a notification first on the
server and then when the buyer closes the payment screen the
client side as well.
And now Luke will tell you more about how this
will work in flash.

LUKE BAYES: Hey, there.
My name 's Luke, and I've been working with these guys since
back in the Jambool days.
I'm going to talk to you today a little bit about the flash
integration and as well as a few other sort of technical
details as we got into it.
So jumping right in here, this API is actually going to be
coming soon, so we're not shipping this today.
But in the coming--
we'll get this as soon as we can.
We'll get this out to you.
If you want to integrate this API with a flash application
or a flash game, the first thing you need do is get our
library, our SWF library.
You'll download that from our merchant area.
And you'll get that into your SWF file, compiled
into your SWF file.
You can do that using the line command
compiler, as you see here.
But you could also use whatever other tools used to
build your SWF application.
So if you're using flash authoring for example or flash
builder or flex builder or FDT, whatever tool you're
using to build your flash application you just embed our
library in there as a SWC file, and you can then make
references to the code that's compiled inside of it.
Now, the second thing you'll need to do is get access to a
signed item token.
And again, you'll need to do that on your server because
you don't want to compile your secret key into your running
SWF file that's then in people's browsers
and stuff like that.
So similar or the JavaScript side.
Now, here we're showing an example of how to do that
using FlashVars or object embed using
the SWF object library.
Now this bottom snippet here is presumably on an HTML page
that your server is rendering in the same way that they
rendered the HTML page as the host did
the JavaScript client.
Now, in this case, we're just sending the same item token
there, and we're pushing it into using a SWF
object dot add param.
Now this implementation can work with exactly the same
back end that's driving your HTML JavaScript client.
So you could, it's conceivable that you could have a flash
game or flash application that's running one
environment, an HTML JavaScript application that's
the same application or very similar, running for another
environment that may not work for flash.
But your service layer could actually be identical.
No some people aren't going to be having just one single
button or one single item to purchase and FlashVars may not
be appropriate.
And in that case you can actually write an API, like
for example, maybe a catalog API.
So you're basically loading a collection of items off of
your server.
And all you have to do is include a signed token for
each item that the user may purchase in the client.
So that would work as well.
Now, the next step is we're going to get down into the
running SWF file.
So into your application we're writing action
script three code.
Now, this code is regular, plain, old
action script three.
This is not you don't have to have a flex application.
If you do that's fine.
There's no frameworks or additional code code that need
to bring in.
But if you have other frameworks it works fine
alongside those.
So in this case we're going to take the buy button that you
presumable have in your app.
And like Mikhail said for the JavaScript side.
It could be some interaction took place.
Maybe you have a vampire that walked up to another vampire
and when they collide the buy screen
shows up for some reason.
In this case we've got a buy button, and in our handler
we're going to attach to the mouse event some
of you may see there.
where in our handler we're going to basically go out to
the FlashVars that we saw on the previous screen, and grab
that item token as a string.
So it's as an opaque string from the perspective of the
running flash app.
We're going to instantiate our library that came in in that
SWC file, and call buy item, sending it that token.
Now this is going to load and display the payment experience
directly within your flash app.
So you'll be ready to go, the user will be able to finish
their, make their purchasee.
And then when they're done you'll get an event you can
subscribe to an optional event like Mikhail described, but
you'll definitely get a post back on your server.
So you can basically handle that post back and award the
item to the user.
I'm going to talk a little bit about JSON web tokens.
So to be clear, this is a scheme that's
in place for signing.
And the purpose of these tokens is for us to verify
that you were in the person, you the seller were the person
who created this particular item and associated this
particular price and wanted to award it to
this particular user.
So what we're doing here is we're verifying that the price
you've given us and who we're going to pay when we collect
that user's money.
So we don't want to let users in the middle, like, open up
Firebug and manipulate the amount they're going to pay
for something.
And we certainly don't want to let them manipulate who we're
going to pay when they give us that money.
So the important thing here is that we have your secret key
is what you use on your server and you use it to sign that
information.
So you create that packet of information and then you sign
it with your secret key.
And then you take that encoded string as a opaque package,
and you pass it through to our APIs and your client.
Now, the JSON web tokens is a very recent innovation in sort
of signing technology these days.
There are a variety of libraries available to use
that work just great.
In getting this to work, we actually came through a few
other implementations, one of them being OAuth1 style
signing schemes.
Now, some you might be familiar with OAuth One
Essentially this is an HTTP coupled signing scheme where
you take HTTP parameters and you sort them according to
some rules alphabetically.
Then you put some delimiters in there and you assemble
them, and it's pretty complicated.
And the problem is it ties your signing scheme literally
to your web server or web application layer.
With JSON web tokens you can actually sign these with
native libraries in whatever language it's written in.
You don't have to know what object, for example, on a
rails app we have a params object where parameters live.
And JSON so OAuth1 was very complicated.
We got into issues at Social Gold where we had a lot of
people having trouble with did I get these
in the right order?
What do I do with optional parameters?
What do I do with other parameters that aren't even
related to this signing scheme.
I've got some method parameter i want to send to do an HTTP
delete or what have you.
Now, all that stuff goes away JSON web token.
So we were really excited when we found this.
And basically with this scheme you just send a packet to this
method in a library and you get back the token.
And on the other side of that you can send the token into
this library and get back the packet that
was originally sent.
It's really simple.
It's really easy.
And there's libraries in just about any language.
So we're working with the library developers.
If you do find a library in some other language that's not
quite up to speed, just let us know on our developer forums.
And we're working on getting all those libraries up to
speed and keeping them up to date with the latest version
of the JSON web token spec.
So with this spec, we also have built a little bit of
support into our merchant center here, where you can
take the parameters, as you're trying to integrate you can
take the parameters that you've got and you can put
them into this web form and hit go and then see a token
get built in place.
You can actually paste that code in and make it make a
call to make sure wheres the problem as
you're trying to debug.
This'll take-- is my signing code the problem, or is my
application code the problem?
Is the library the problem, like, what's happening?
This let you narrow that problem set down and see my
signing code is actually generating a different
signature with these inputs, there must be a problem in my
signing code, perhaps in the library, perhaps in
how I'm using it.
And this is a great tool that I think will be really helpful
for a lot of people.
Now some of you may have noticed that as we look at
those diagrams that Mikahil had, we had this process
beginning in a client, in a browser of some kind
somewhere, and then our servers are
calling your servers.
Now there's a little bit of an issue there in that you're
probably wondering how do I know which user was in that
browser in order to associate this purchase and give them
the right thing?
Well, the way we're encouraging you to do that is
through this field called seller data, which is just a
field on the hash that you send to the library, to the
signing library.
Put this in your JSON web token.
It's an opaque string from our perspective.
We don't care what's in there.
You can put whatever you want in there, and you can use it
to associate a purchase with a user in your context.
So we're not going to leak user data to you, and we're
prefer it if you didn't leak user data to us.
And it's important that you encrypt that date.
Now, as I said before, JSON web tokens
is a signing scheme.
It's not an encryption scheme.
So we're relying on HTTPS for encryption, but we want to
make sure that you keep your user information secure
according to the terms of your relationship with your users.
And that means secure from us as well.
So you should encrypt that information.
If you put personally identifying information there
you should encrypt it as you send it in, and you should
decrypt it when you get it out.
And we're going to pass it through.
So we're going to send you back a JSON web token that's
very similar, but not the same as the one that you sent that.
And when we send that back we'll include whatever you
gave us an that [UNINTELLIGIBLE]
data field.
And that will allow you to do things like hey, I just got a
post back that said someone bought something.
Here's who bought it, user ID 12345.
But you can also do interesting things in addition
to that, like, oh, actually this session was initiated
from this refer from one of my partners and I want to award
them some percentage of that fee since I made so much money
only giving Google 5%, right?
So now then basically you can have these sales.
You can have discounts.
You can have refers.
You can put whatever you want in there.
And you can structure that information however you want
as long as it encodes and decodes to JSON.
So if you want to but some other binary blob in there and
just encode it as a string, that's fine.
Now, I'm going to wrap up with that, and bring Amit up here
to finish this thing up.
Thank you.

AMIT FULAY: Thanks, Luke and Mikhail and Jake.
Hopefully that gives you a sense of what the experience
is, what the API set looks like.
Just to quickly recap simplicity has been a core
focus in all aspects of the product that we've built, API,
user experience, as well as pricing.
You can get started today.
There's a short URL for you to remember.
That's the home page for in-app payments.
If you already have an account you can sign in or you can
create a new account.
API is available for you to play with.
The documentation is available.
We have a Google group that we will be actively monitoring,
including the engineering and the product team.
So if you have questions, you have feedback, please
do send it to us.
Once again, the hope is we can fill the gaps in anything that
you think is missing, give you some lead time to integrate
all of your apps with this new payments platform.
And come summer let delight users and make some money.
Thank you
If you have questions, please go up to the mike.
Mikhail, Luke you want to come here.
We can answer any questions you have. Please?
AUDIENCE: Hi.
I have a couple of places actually, and just looking at
it, can you hear me?
AMIT FULAY: Yes, if you come a little closer.
AUDIENCE: So I have a couple of questions.
I can see in the URL that if somehow a brother to
Google check out.
Is that also why the postback for the yes or no pretty much
when I send the payment yes or no it's still asynchronous?
Why can't I just get that reply right there instead of
me trying to identify the just like any kind of credit card
processing, pretty much like in a gateway process.
Is that is that also why that is?
AMIT FULAY: Okay, so first let me summarize the questions.
There's two parts to your question.
AUDIENCE: Yeah Yes, exactly.
AMIT FULAY: The first part is, is it still check out UC check
out in the URL somewhere, and the second was is it
asynchronous or not?
AUDIENCE: Yes because in that demo the server gets a post
which pretty much says whether or not the transaction was
good or not, instead of me getting it at
the point of purchase.
So there's this flow that's synchronous, and then there's
the flow that's asynchronous that's happening in the
background that I have to somehow poll before I give
access to something.
If I had that synchronously then it's right there.
It happens right there.
AMIT FULAY: That's a great question, so let me answer the
first part and I'll let Mikhail
answer the second part.
As far as check out is concerned, so I showed in the
diagram the whole Google payments infrastructure.
Check out is also built on top of that.
Check out was a product that was tailored towards physical
goods, shipping goods, that e-commerce wave
that I talked about.
And we're taking that payments kind of platform and building
and innovating on top that.
So you're seeing in-app payments being the first kind
of incarnation.
Check out was the older one for the physical goods, and
you'll see some more offerings coming from us in the future.
As far as the synchronous transactions, I'll let Mikhail
answer that.
MIKHAIL SEREGINE: Yes, so regarding the synchronous
transactions, I think we actually made it as close to
synchronous as possible in JavaScript So when you open
the payment screen you don't want that buy item call you
first make to be synchronous because you don't want it to
block the whole thread.
And so that's why we had to make the JavaScript call backs
on the other side be call backs instead of just the
return of that call.
The reason it's very close to synchronous is because that
server post back is guaranteed to finish before the
JavaScript call backs are invoked.
So you actually don't have to do the polling.
You can just check at the time of the call back.

AMIT FULAY: Yes please go ahead.
Next question?
AUDIENCE: So this is cool, but what if I mean, I like how
fast it goes, but what if my users don't want quite that
experience?
You know the problem with kids using daddy's credit card for
too fast of an in-app purchase.
Or the reverse of that, what if there's a user time out, if
the user gets up and leaves and comes back and completes
his transaction half an hour later.
How do those kind of cases--
AMIT FULAY: It's a great question.
So let me to repeat for the recording here.
It sometimes goes too fast. What happens to users who are
probably not trained, do they end up making purchases when
they don't even realize it?
I think that's the question, and that's a fair point.
We did think about this, and if you there is today in the
payments experience an acknowledgement, a complete.
The user has to explicitly agree to buy an item before
the purchase completes.
We had talked about coming up with a model that's only
single click.
So you basically click on an item and you get it.
You don't even have to acknowledge if
you trust that developer.
So there is kind of a fine balance, and this is something
I think will have to evolve the model
as we get more feedback.
But we have kept this experience.
It is kind of two step simply to kind of avoid that problem.
MIKHAIL SEREGINE: And just to add a little bit to that, I
think that's one of the things we're refining during this
trial period where you guys are integrating and asking us
these questions.
So that was an issue that came up.
We these steps that Amit described to address them, and
we are thinking about doing more things.
LUKE BAYES: And to add to that, I think there's the
expire field as well, so developer to developer.
Control that to some extent?
How long their signatures are valid, for example?
MIKHAIL SEREGINE: Yes so you can the developers have some
control over how long those purchase tokens are valid.
So they're valid indefinitely.
AUDIENCE: Yes, okay, so do you have any--
since you didn't talk about it, I'm going to assume that
there's no support for a subscription model then?
AMIT FULAY: So the question is is there support for
subscription model?
We don't have in the product we are launching today.
That's something that we are going to build
in the coming months.
AUDIENCE: Okay.
And do you also have APIs and such so that since you're
handling the payment and such, do you have APIs avaliable so
that we could query what is the transaction history of a
given user so that we don't have to keep any logging on
our end as far as what happened and who paid
what and all that?
MIKHAIL SEREGINE: Not at this time.

AUDIENCE: Hello, I have a question about the revelation
with Android purchase and what if we have the same code base
for Chrome app and in JavaScript and a Android app
in a package like phone gap or something?
Can we use that or are we supposed to use two different
payment system?
AMIT FULAY: Yes, so the question is how does it relate
to Android app, if I were to paraphrase that.
Actually I see some of the folks leaving so I'm going to
interrupt the answer one minute, and we do have some
special session t-shirts that you should collect on your way
out if you are leaving.
But coming back to the question, Android app, which
is the mobile app.
So there's a couple of kind of clarifications I'll make,
which is we're using the same underlying payments
infrastructure.
And when I talked about that account, the user base that
has transacted on any of these properties that kind of comes
with along.
So the user that's an Android app that created an account
there, that's applicable here.
They have single signing.
So as far as the payments underlying
infrastructure that is shared.
Now, mobile and a pure web, they are
inherently different models.
You see that difference between Chrome web store and
mobile specific marketplaces.
And so the pricing structure will be what
applies to either case.
Yes, please.
AUDIENCE: This is a question to add on to the first person.
So if of call back to the server is synchronous right So
what happens if the server end we cannot handle it.
For example like our game server may be overloaded.
So you send this to us, like we cannot deliver the good
because like that there's some issue with the system.
Is the transaction comes through that completed or is
the transaction--
or do we have to do something as to tell is that we're
having some Issues
AMIT FULAY: Yes, please.
Could you please repeat the question?
MIKHAIL SEREGINE: The question was what happens if you
couldn't acknowledge the post back or if you return an error
instead of a success on that post bask acknowledgement.
LUKE BAYES: And/or a time out.
MIKHAIL SEREGINE: Or a time out.
And the answer is that at that point the buyer is still
looking at the payment screen and we show them that we could
not deliver the item and that that order will be cancelled.
AUDIENCE: Can I do something like a return to using the
transaction is completed on my end but it's going to later to
deliver to the user?
MIKHAIL SEREGINE: No, we want the user experience to be
either successful or a failure.
So that if they want to get the purchase later they just
have to go again and try it again.
AUDIENCE: Okay, so what would you suggest in the case of
like a massive sale, like let's say the
game is really popular.
They're doing a flash sale for like five minute or an hour?
LUKE BAYES: You should host your app on app engine.
[LAUGHTER]

MIKHAIL SEREGINE: So in order, if the users can't get the
thing they're buying, then that's a
part of the same problem.
Is if your app is overloaded they might not even be able to
get to the purchase screen.
So if that part of app works then the postback handling
should also work.
LUKE BAYES: And the truth is this is an in-app experience.
So this is a user who was in your app, let's use a game as
an example.
So they're in the and they'e just they're getting
frustrated in Angry Birds and they can't.
They want that eagle and they want to do it, and they click
buy, and then you want to tell them no, you can't have it for
like a day or two.
So in this case because we're in-app it's not like something
you're buying that might ship tomorrow from Amazon It's
something they want right now.
They went immediate gratification.
So we're thinking of it from the user's perspective.
They either want it or they don't want to
be charged for it.
And this is something we learned at Jambool,
at Social Gold was--
AUDIENCE: But I'm not talking about day.
I'm talking about like let's say five minute
or something shorter.
It's just not like 30 seconds.
LUKE BAYES: We should probably talk about that.
So that's actually--
AUDIENCE: Yes, okay Thank you.
I don't want to talk.
AMIT FULAY: The gentleman in the back?
AUDIENCE: So what about support, like if there's a to
user has any need dispute, anything that does the poll
goes to direct, goes to Google first or go to like the app
seller first?
AMIT FULAY: So the question is the Google group, who's
supporting that.
AUDIENCE: No like the user support.
AMIT FULAY: Oh the user support.
AUDIENCE: Support for the user.
AMIT FULAY: I see.
So as far as the payments dispute what happened to my
credit card?
It didn't go through.
that is all using the existing support mechanisms that we
have with Google payments.
That's is also with check out, so we will have the same
support team, sensible same support forums. that you'll
get for the end user.
So you'll get that.
LUKE BAYES: But we're growing that.
AMIT FULAY: Yes, and we're staffing it as we get more
developers.
So does that answer your Question
AUDIENCE: Yes.
And a second question is how to handle refund?
AMIT FULAY: How do you handle refunds?
AUDIENCE: Yeah.
AMIT FULAY: So we are actually working through the whole
refund chargeback policy.
If you subscribe to the groups we'll do
an update very shortly.
AUDIENCE: Okay, and one more question is that so you say
that the flash API is not yet available but I think Plants
Versus Zombies is a flash game and how do they integrate?
AMIT FULAY: So the question is flash API is not available,
Plants Versus Zombies is a flash game.
So Jake, I can answer on his behalf.
I think they are using PopCap has moved to using am HTML
based payments flow.
So They are using the HTML version, JavaScript
version of the API.
LUKE BAYES: And I can answer that a little bit, too.
Many flash games use a window mode setting when they embed
their script that draws directly to the screen.
And some flash games don't, some flash games do.
Depending how that setting is done, you may or may not be
able to overlay an iframe above a flash--
a running flash application.
And so our flash API is specifically and especially
for those games or applications that cannot
overlay an iframe and want to have the application, all the
application handling done directly in
action script three.
But you can, if you're in the case where you can overlay,
you can pretty easily use external interface or some
other means to talk to JavaScript on the page and
load iframe above your app and let it close and get the call
backs that way.

AMIT FULAY: It should be on now.
Try.
LUKE BAYES: Try now.
AUDIENCE: Hello.
Yes.
So basically they are using as standard interface code to
invoke the JavaScript, yes, is how they--
LUKE BAYES: I believe so.
Is it?
I assume that's true.
Yes, I'm getting nods over here.
That's sounds right.
for this demo, yes.
AMIT FULAY: And the PopCap, a couple of folks from PopCap
are also here so you can, if you have more follow-up
questions, feel free to ask them.
AUDIENCE: All right. thank you
LUKE BAYES: Thank you.
AMIT FULAY: We'll take a question in the back.
AUDIENCE: How do I get it?
AMIT FULAY: How do I get what?
AUDIENCE: How do I sign up to be a--
AMIT FULAY: Ah, so there's a URL here to sign up.
And probably this is the one on the top that you're going
to remember.
So go to goo.gl/5percentfees it will take you
to the sign up page.
AUDIENCE: Cool.
And is there a minimum browser level for this?
I mean does this support like IOS three or Android 2.0 or
IE7 or that kind of stuff?
AMIT FULAY: So the question is, is
there a minimum browser?
So we are supporting all standard browsers.
It's in our documentation.
I believe it's IE7 and above, FireFox 3.0 Android browser,
Safari, so we'll support all standard browsers.
LUKE BAYES: I think we're tailoring the experience right
now for the desktop, to clarify that.
AMIT FULAY: Yes.
AUDIENCE: So I wanted to ask a follow-up question about the
Android thing?
So I understood Android store has a different cut, and there
whole lots of reasons for that.
But if I do an Android app and I use your API to do an in-app
purchase, are you going to disable that?
Are you going to take a different cut because it's an
Android app?
How's that going to work?
AMIT FULAY: So the question is there are different models of
Android on the web.
What happens if you build an Android app and use our API?
You cannot use this API for native Android apps.
Anything that's a web app and if you're on the phone and
you're using the web and you're getting to your app
through the web, it's not a native app, then you
can use this API.
So there's a distinction between native and web apps.
This platform is for wherever web apps.
AUDIENCE: Okay, thanks.
AMIT FULAY: Yes, next question?
AUDIENCE: When will you make this available for
international developers?
AMIT FULAY: Yes that's a great question, when will you make
it available for international developers?
I mentioned we're going to go live in summer.
At that point we'll support all our international
developers.
So whatever Google payments supports, I think I believe
it's 21 countries, several countries, so you can have 21
different locations where developers can sign up and
have local currencies and stuff like that.
So the summer launch will have the international component.
Yes please go.
AUDIENCE: Yes, obviously kind of excited about this.
You said that this was based on the payments platform, so
can we leverage our existing checkout, the notifications,
the signing, and all that?
Or is this totally different?
AMIT FULAY: So question is can you leverage the
notifications?
AUDIENCE: Yes.
Because you said that this was somehow on top of that whole
payments infrastructure, which is where checkout is also
based out of.
Can we leverage existing knowledge already about the
API for checkout, for example, like the notification?
There's some similarity in there and then the signing and
all that, so just wondering?
LUKE BAYES: It will be similar, but
it's not the same.
So you will have to go do this in-app integration.
AMIT FULAY: I mean one other focus has been that you don't
have to worry about a lot of concepts when you integrate.
So in the check out classical physical goods
model you have carts.
You have shipping.
Taxes, You have to worry about a lot of things.
And the API actually hides all of that complexity.
It's basically price, currency and description, and that's
all you need to worry about.
So our hope is you don't have to use some of
the different models.
That's good.
Gentleman in the back and then I'll take your question.
AUDIENCE: Which group of international developers are
going to get access to this?
Is it going to be the ones that can sell on Android or
the ones that can sell any Google checkout.
Countries like Canada can't do Google checkout yet.
AMIT FULAY: So the question is regarding Canada.
I don't have an accurate answer for you right now.
But we will follow-up in our groups postings
so please do subscribe.
And we'll actually publish a detailed an international
rollout plan.
AUDIENCE: Yes.
I have a vertical portal, okay, website.
So would it be possible to implement the Google payments
in that website?
And in that case will it compete with Google, PayPal,
and all of the other types of checkout
that are in the market?
AMIT FULAY: So I'll repeat your question.
You have a vertical website where you want to integrate
payments, and will this platform work?
Absolutely.
As I said, this is not only Chrome web store, for any web
app on the web.
So you can integrate it no matter where
your application resides.
I'm not sure about the second part of your question?
AUDIENCE: Yes, the second part is when you have the check out
and if you can integrate this, the Google app, and then you
also have, for example, the PayPal type payment, and then
the user will have to choose one of them to check out.
So basically they are competing and is the one who
will decide will be the user either to take the Google one
or the PayPal one?
AMIT FULAY: Yes, absolutely.
So the question is if you have competing payment options, and
I think that's fair.
There's nothing that precludes you from doing that.
You can have PayPal, Amazon, Google.
That's kind of a practice.
A lot of websites accept payments from different
things, and it's up to your users what
they want to choose.
So you can absolutely do that.
LUKE BAYES: There is one more thing to clarify.
This is, and I don't think it was made clear.
This is for virtual and digital goods.
So if you have a website that sells physical products to
people that you mail to them, then this is not appropriate
API for you.
So we certainly could be nest to a PayPal button for virtual
digital goods in an environment like that.
AUDIENCE: Will it develop into that in the future?
LUKE BAYES: We'll see how the platform evolves.

AUDIENCE: So i have a lot of questions here, the first one
is what kind of user data we have?
Like, can we get even like user name
or address, or anything?
And the second one is like what kind of user analytics
you provide if we use this API?
Thanks.
AMIT FULAY: So I'll repeat the question.
What kind of user data we have so could you--
AUDIENCE: If user purchase any virtual good, right, I assume
my system knows like what's the first name and the last
name and address and everything, all right?
So what kind of user data we as like the vendor or the
developer gets?
AMIT FULAY: Yes.
So the question is what of user data that Google
collection will be shared with developers?
AUDIENCE: Yes, exactly.
AMIT FULAY: So that the data, because it's very sensitive,
so it's an NPAI.
It's credentials, payments credentials, address, name, we
do not share this data--
AUDIENCE: Okay.
AMIT FULAY: with any developer.
AUDIENCE: Okay so then what kind of like user
analytics do we have?
Like do you know, like, I don't know, maybe to age
between, like, 25 to 35 purchase this item within the
first month or something like that, concerning analytics.
AMIT FULAY: You're not looking for a analytics with the
demographic data.
We don't have that today.
Our analytics is basically across the user base.
It's anonymized so we basically tell you how they
are converting.
AUDIENCE: Exactly.
Thanks.
LUKE BAYES: And again, we have our forums are open so we're
hoping that questions, like that, like you guys can help
guide the product as we work this summer over it.
AMIT FULAY: Thank you for your time and patience.
I'm being asked to leave and vacate the stage.
Thanks.
Thanks for joining us.