Google Payments - Wallet APIs Office Hours

MIHAI IONESCU: Hello, everyone.
Welcome to Payments Live.
We have an office hours slide show today, answering
questions from Stack Overflow groups and the moderator.
But before doing that, we'll do something special.
Here in the studio with me is my colleague, Peng.
Peng.
PENG YING: Hey, how's it going?
MIHAI IONESCU: Say hey to everyone.
And what we are doing is, as we are getting close to the
end of a great year for Google Payments and Wallet APIs, and
since this will be the last show until next year, we
thought let's do a recap of all the important events and
launches that happened in 2012.
So let's get started.
Just as we crossed into 2012, we launched the international
introduction of the digital goods API
or the In-App Payments.
And that came with the availability in 18 countries
and nine currencies.
And it was a nice, new present.
And we made quite a [INAUDIBLE]
developers very happy.
Pong, what happened next?
PENG YING: And shortly after we launched that, we also made
a few additional improvements [INAUDIBLE].
We've added a streamlined sign-up.
We call that [? mailing ?] address sign-up.
And it makes it a very seamless experience to
purchase virtual goods from within the app.
So we simplified sign-ups for in-app payments.
MIHAI IONESCU: So now even the sign-up was in-app.
That's pretty cool.
And along the way, we also had some cool developer
conferences and events, where we met a lot of developers, we
talked about the multi-synch apps, the Google Wallet.
And among those, some of the most important work, the
Google Developer Conference, [INAUDIBLE]
Conference, and South by Southwest.
Both happened in early spring.
And they're coming again this spring in 2013.
And we may have some cool things to talk about.
So stay tuned for the announcements.
We try to post the announcements in
advance on this show.
PENG YING: And then in March and April, we also announced
mobile web support for in-app payments to API.
And what this means is that you can just integrate once,
and you will be able to accept purchases on the desktop and
mobile devices while on the mobile web.
We also launched a Google+ page for Google Wallet to keep
you up to date on the latest Google Wallet news.
And in June, at Google I/O, we had a few other great new
announcements.
We launched subscription support and a new pricing
structure with fees as lows as 1.9%.
Oh, and we also announced Save to Wallet for offers.
MIHAI IONESCU: Lots of announcements at
I/O. That's very nice.
And then the summer came, and what did we do?
We took a vacation?
Not really.
Just right after Google I/O, we launched this show on
Google Developers Live.
It's an amazing way to reach developers in all
parts of the world.
We hold office hours and [INAUDIBLE].
We try to give you a sneak preview into things to come.
And to name just a few, we showed you the new Merchant
Center, and also the new commerce [INAUDIBLE]
features.
And the all these are very nice new features that will
come in the coming months.

PENG YING: And then in August, we did something new.
We moved the concept of Google Wallet into the cloud.
So now instead of digitally representing your credentials
on your phone or your device, we are now storing digital
representation in the clouds.
And the benefit of that is that it's now accessible from
any device connected to the clouds or even off-line
sometimes, depending on the device, that
supports Google Wallets.
Anywhere you want to purchase from, whether it's your mobile
phone, whether it's your tablet, whether it's your PC,
on any purchase flow that supports Google Wallet, you
can make a purchase using the same credentials across all of
those things.
MIHAI IONESCU: That's really cool.
That was one big step forward.
You used to have only one card available on Google Wallet.
Now you can have any of them.
And the cloud gives you so many more security
enhancements and new features.
And with all those things going along, we kept in touch
with the developers through our Payments Live show.
But we also like to meet face-to-face.
And in early fall, we had quite a few conferences, where
again we met with developers and talked about Wallet APIs.
And we had a lot of what we call [INAUDIBLE], sponsored by
Google and local developer communities in Washington, DC,
and in Mountain View California.
To all those people there, if you're watching, hi!
Later on this fall, we met with quite a few people in
Kansas City.
And these are all great ways to connect with developers.
And we'll make sure to let you know about
any upcoming events.
PENG YING: And finally, closer to the end of year, we
announced a new mobile wallet API for mobile web
transactions.
What it does is it enables OAuth 2 like access to carrier
credentials.
Currently, it's only available to select merchants.
But we're accepting new merchants every day, and you
can request to be a merchant on our site at
developers.googl e.com/wallet-online.
MIHAI IONESCU: And of course, we kept announcing more and
more mobile devices that come preloaded with Google Wallet.
And the last few we mentioned in previous shows are from the
Nexus line.
Phones and tablets from Samsung and LG.
And let's see.
So we got closer to the end of the year.
What else?
Oh, on the developer support front, we are now focusing and
have centralized the support to Stack Overflow.
And this is where we'll actually take
some questions today.
And on Stack Overflow, please make sure you only use
technical questions.
Either too generic or not on technical topics, they may not
be accepted.
PENG YING: Yeah.
They may get closed out by the community or
down-voted into oblivion.
MIHAI IONESCU: Yep.
All right.
So what a great year.
With that, let's move on with the Q&A section.
So let me start with the first question.
We had quite a few on Google Checkout.
And this one involves the carrier-calculated shipping
API, a very nice feature of Checkout.
And the question is, I'm using the Checkout
carrier shipping API.
I have three shipping methods set up, and they work fine.
I added a new set of products, and for those, the Checkout
order page only shows the default shipping costs.
So obviously, your carrier-calculated shipping
methods are not applying to these new products.
It should be relatively easy to debug and test this in the
sandbox, because you can then complete the entire
transaction.
You don't just stop at the order page.
And then you can analyze the shopping cart [INAUDIBLE]
Google to try to figure out why only the default shipping
cost is applied.
But if you cannot do that, since this is happening only
for those new items, that's a pretty good indication that
there's something probably wrong with those.
There's some missing or incorrect data in the
inventory when you added them to your database.
And to give you a way to start investigating, please know
that carrier-calculated shipping needs the item weight
in order to calculate the total shipping cost, because
carriers calculate cost based on weight.
And most likely, you have weights
missing on those items.
And that's why by default there is zero, and then
carrier-calculated shipping will use the default cost.
And another thing to make sure regarding to weights is that
the total weight of the package will have to be at
least 1/4 pound in order for carrier
calculated shipping to apply.
So if you have smaller items, just set them to 0.25 pounds,
or 1/4 pound, and then the shipping methods will kick in.
So I think, probably, this is what's happening, and you'll
figure it out.
PENG YING: Yeah.
Seems like it.
I've seen a lot of issues, and most of them are mainly around
the weight.
MIHAI IONESCU: It's easy to miss.
And when you're adding new items to inventory, it's easy
to miss the weights, or add smaller weights than is
actually the case.
PENG YING: True.
I'll take the second question.
So I have trouble with taxes in Checkout.
The taxes set in the Merchant Center are not applied.
And then I've seen this a few times before as well.
And what's typically occurring here is that I'm guessing that
the merchant is using an e-commerce platform.
And e-commerce platforms also sometimes can include their
own tax rules.
And these tax rules are defined within the shopping
cart XML that your platform is sending over the Checkout and
overwrites the tax rules that are defined within Checkout.
So you're probably seeing the default tax rules that the
e-commerce platform has provided.
To get rid of this or fix this, you have two options.
You could either fix the tax data or update the tax
[INAUDIBLE] within your e-commerce platform, or you
could ask your e-commerce provider how to remove the tax
rules from [INAUDIBLE].
MIHAI IONESCU: Makes sense.
Let me take the next one.
So the question is about passing specific order
information and private merchant information in a
Google Wallet transaction.
And I think we touched on this topic before.

Most wallet APIs give you a way to ask private merchant
information [INAUDIBLE]
back to you so that you cannot associate that information
with the order.
So since this does not mention the particular wallet API, let
me talk about two of them that offer this capability.
For the digital goods API and the In-App Payments API,
there's a field called "Seller Data," where you can pass
private information.
Probably it's a good idea to encrypt it.
And this information will be sent back to you in the
postback or when the transaction completes.
And you can use it to update your inventory, your user
management information, everything there.
And similarly, on the Checkout side, there is a "Merchant
Private Data" field in the XML.
Merchant-private-data.
You can search for it in the documentation.
Which behaves in a similar way, and you'll receive the
same data back through the notification API.
So two different APIs.
Similar methods to handle merchant information.
PENG YING: I'll take the next one.
So how can I change the order page to get the
customer on my site?
The guy in this one doesn't really talk about the API or
what part of the order flow.
So I'll answer all of the possibilities.
First off, in Checkout, there's [? no ?] automatically
corrects everything.
So in order to get the customer back to your page,
the customer needs to take action.
If it's during the initial checkout flow, where they're
still viewing the order on Checkout, you could do find
and edit [INAUDIBLE], and then that'll create a link on the
checkout page that will allow the user to go back to your
site to edit the items in their cart.
Once the user has completed the purchase, you can define a
Continue Shopping URL, which will define a link to direct
the customer back from the receipt page to your site.
But if you're only selling digital goods, you can use the
In-App Payments API or Google Wallet for Digital Goods,
where the entire flow takes place on your site, and you
won't have any of these problems.
MIHAI IONESCU: Yeah.
Much, much easier.
PENG YING: I hope that answers.
MIHAI IONESCU: Yes.

All right.
There's another one about pricing.
Do you want to take it?
PENG YING: MIHAI IONESCU: Oh, yeah.
So this one is actually from Stack Overflow.
And it's a little bit un-technical for Stack
Overflow, but we answered it anyway.
In Google Wallet, I set the price in US dollars, but I'm
selling digital goods, and my customer might be
anywhere in the world.
Is there any way you see what Google Wallet will charge in
localized currency?
So this is kind of the opposite concept of how Google
Wallet works.
Instead of you setting a fixed price as a merchant, and then
expecting Google Wallet to translate it across various
currencies--
well, how it actually works is that you set a fixed price in
that currency, and then we translate it to US dollars, or
whatever your merchant account is in, and then pay you out in
that amount.
So it's the opposite.
And what you should do is IP geolocate your customer, then
define the market price of the item in the geolocator
currency, and enable your customer purchase that way.
With that, instead of maybe one day your customer gets
charged $0.05, and then the next day your customer gets
charged $0.25, it's just a fixed amount the entire time.
And then that currency conversion risk is
handled on your side.
MIHAI IONESCU: OK.
Let me take the next one.
This is also Checkout related.
Oh, that's quite a few of Checkout questions.
It says, I'm using the Checkout notification XML API,
and Google seems to be delivering notifications not
in the order I expected.
For example, an order state change notification will have
a new financial order state of charging, and then immediately
after one proceeding, it had already said it would charge.
So all the notifications may come out of order.
And especially for order state changes.
The only Checkout notification that is guaranteed to arrive
in order, it's the new order notification, which will
arrive first.
So you'll get that one, and then you may get some order
state changes notification in not the
order you're expecting.

Your solution sounds fine--
setting the state of the order to the order state
notification with a high serial number, it's OK.
PENG YING: And I'll take the last question.
Is it possible to cancel a subscription for a user
without issuing a refund?
So there was some confusion about cancellations of
subscriptions and whether that would automatically refund the
subscription amount or the latest charge.
And we want to clarify that.
Cancelling a subscription--
well, all it does is it prevents the
recurrences from occurring.
So if there was an initial amount tied to that
subscription initiation, then you can
also refund that amount.
But cancelling the subscription won't refund the
subsequent orders.
So if you want to refund each of those subsequent
recurrences, you'll have to go into those recurrences, and
then cancel and refund those.
MIHAI IONESCU: All right.
Any more questions?
We got to the end.
PENG YING: I think that's it.
MIHAI IONESCU: That's it.
Lots of Checkout questions.
People are getting ready to sell stuff for New Year and
Christmas, and all the winter holidays.
So we hope we make money!
[LAUGHTER]
MIHAI IONESCU: Great.
So this, as we said earlier, this is last
show for this year.
And we will see everyone back in 2013.
We want to wish you a happy New Year.
PENG YING: Yeah.
Happy holidays.
MIHAI IONESCU: Happy holidays.
And we'll see you in 2013,
PENG YING: See ya.
MIHAI IONESCU: Bye.