[FR] getSkuDetails() should have a flag to return prices w/ ISO 4217 currency code instead of currency symbol

[GoogleCodeExporter]

We have realized that in the In-App billing APIv3 when you retrieve the 
products info, google gives you the item price with the currency symbol.

In our case, we are storing all the financial transactions in a database for 
internal analysis and with this info we cannot differentiate for example 
between USD and CAD because both shares the same symbol. 

We request to change the answer for this method and include the ISO 4217 code 
on the item price instead of the currency symbol. It is less ambiguous and it 
allows you to get the currency symbol from the Currency Java Class.

Original issue reported on code.google.com by djsatano...@gmail.com on 11 Jan 2013 at 7:30

[GoogleCodeExporter]

That API endpoint is meant to produce a string that can be displayed to the 
user in a user-friendly way, that's why it uses the human-readable currency 
symbol instead of the currency code. There should probably be a flag or an 
extra parameter to specify whether you want the prices formatted for display or 
not. I'll put that down as a feature request. Thanks!

Original comment by b...@google.com on 5 Feb 2013 at 7:27

• Changed title: [FR] getSkuDetails() should have a flag to return prices w/ ISO 4217 currency code instead of currency symbol
• Changed state: Accepted
• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

We have the same issue - is there an estimated timeline for this feature? 

Original comment by sana...@gmail.com on 15 Feb 2013 at 2:24

[GoogleCodeExporter]

"That API endpoint is meant to produce a string that can be displayed to the 
user in a user-friendly way"

Does that mean the approach Google Play uses on the confirmation screen is 
user-unfriendly because it shows the format as "CA$1.99"? Even being able to 
get that format instead of the proper ISO 4217 would be beneficial in certain 
situations. 

Original comment by chris.pr...@gmail.com on 3 Apr 2013 at 9:50

[GoogleCodeExporter]

We have the same issue, too.
Our app needs both
- price ($0.99) for ui
- iso 4217 currency code(USD), amount number (0.99) for billing server 
management.

Maybe if the response of getSkuDetails includes
'price' as well as 'priceCurrency' and 'priceAmount', it would be best for us.

Original comment by noranb...@gmail.com on 4 Apr 2013 at 6:11

[GoogleCodeExporter]

If this issue takes quite some time to resolve,
Google providing the proper parser($0.99 -> USD, 0.99) would be the second best.

Original comment by noranb...@gmail.com on 4 Apr 2013 at 6:19

[GoogleCodeExporter]

The current behavior is a _nightmare_ and horrible for a payment solution in 
2013. A lot of different currencies share the same curreny sign/symbol!!

Example:

1:00kr (NOK) != 1:00kr (SEK) != 1:00kr (DKK)

This MUST be resolved immediately. I notice this issue is flagged as "priority 
low", but any serious merchant need this fixed NOW.

Original comment by martino...@gmail.com on 12 Apr 2013 at 1:43

[GoogleCodeExporter]

Can someone from Google comment on if this is the correct forum to raise this 
issue? The project description says "Issue tracker for Android Market In-App 
Billing sample code", but this is an issue beyond the sample code that concerns 
the In-App Billing API. 

Original comment by sana...@gmail.com on 12 Apr 2013 at 9:47

[GoogleCodeExporter]

This is the right forum! I'm in touch with the engineers who work on in-app 
billing and I'm keeping an eye on this issue, but we don't have an ETA yet. We 
appreciate your feedback! I'll keep you posted.

Original comment by b...@google.com on 15 Apr 2013 at 4:13

[GoogleCodeExporter]

This is a HUGE problem ! Please fix it :-/

Original comment by jean-bap...@adictiz.com on 26 Apr 2013 at 3:19

[GoogleCodeExporter]

So, our app shouldn't know how much user actually paid? Useless. 

Original comment by ippei.u...@gmail.com on 14 May 2013 at 6:09

[GoogleCodeExporter]

Also suffering from this. We need an urgent fix for it, thanks.

Original comment by gsal...@gmail.com on 22 May 2013 at 7:28

[GoogleCodeExporter]

We also have the same problem. Is there a fix for this issue?

Original comment by Dawid.Ma...@gmail.com on 27 May 2013 at 9:11

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

We are also facing the same issue. Please resolve the same. Thanks
It would be really good if we have a separate field for currency code and the 
price is just a double. 

Original comment by aasha.me...@gmail.com on 27 May 2013 at 12:46

[GoogleCodeExporter]

I think this issue is getting pretty embarrassing. Google have rolled out
at least two updates since the issue was noted here, and in my opinion the
service is totally useless without the requested fix. If the dev team could
just add two new return parameters with the currency and numeric value as
separate fields respectively, no-one _have to_ change their implementation.
There are no obvoius drawbacks either.

This is a major issue to anyone with serious business intentions. I'm very
disappointed so far.

Original comment by martino...@gmail.com on 27 May 2013 at 1:57

[GoogleCodeExporter]

I agree with the comments above.  The priority of this should not be low.  Can 
we get an ETA on a fix for this issue?  One would think that enough time has 
elapsed since this issue was entered to at least have that... 

Original comment by jus...@rowshambow.com on 4 Jun 2013 at 6:38

[GoogleCodeExporter]

Hope they get this fixed in next release !

Original comment by ptyag...@gmail.com on 4 Jun 2013 at 6:45

[GoogleCodeExporter]

I am facing the same issue but don't know where to extract even the "currency 
symbol" since I am seeing getPrice return "$X.XX" with currentSymbol included. 
What does Google Play use to decide currency?

Original comment by kvnfl...@gmail.com on 4 Jun 2013 at 11:53

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

#20: You could extract the symbol from what getPrice() returns, like this:

   String currencySign = formattedPriceFromGetPrice.replaceAll("[0-9.:\\s]","");

..but the symbol is of limited value, as I explained earlier in this issue 
thread (Basically because several currencies share the same symbol).

Original comment by martino...@gmail.com on 5 Jun 2013 at 12:58

[GoogleCodeExporter]

Right. Thanks martino... I thought I was missing a "getCurrencySymbol" call 
outside of SkuDetails. I am having trouble testing in different currencies 
other than my home though. Do you need to register a different country/region's 
credit card on a foreign addressed Google Play/Wallet account?

Original comment by kvnfl...@gmail.com on 5 Jun 2013 at 3:54

[GoogleCodeExporter]

Just a quick note to say we haven't forgotten this feature request :-) We can't 
give an ETA, but it's in our radar. I'm checking on the progress of this 
request regularly.

Original comment by b...@google.com on 25 Jun 2013 at 9:46

• Added labels: Priority-Medium
• Removed labels: Priority-Low

[GoogleCodeExporter]

Thanks for the update.  Does saying that this can be done on iOS light any 
fires under anyone?

Original comment by jus...@rowshambow.com on 25 Jun 2013 at 9:54

[GoogleCodeExporter]

Thanks for the update. Right now, is it correct to get the user's current 
locale in order to determine which currency code the price string is in? Or is 
dependent on the country set in their Google account?

Original comment by ashug...@gmail.com on 25 Jun 2013 at 11:01

[GoogleCodeExporter]

Thanks for the update. It's good to hear that this hasn't been forgotten :)

Original comment by noranb...@gmail.com on 26 Jun 2013 at 1:03

[GoogleCodeExporter]

It's dependent on the credit card origin of their Google Play/Wallet acct.

Original comment by kvnfl...@gmail.com on 26 Jun 2013 at 1:54

[GoogleCodeExporter]

It also depends on wifi ap. I've seen it on my roaming phone that the currency 
is changed after I turned on my wifi.

Original comment by noranb...@gmail.com on 26 Jun 2013 at 3:58

[GoogleCodeExporter]

the kronor problem is even bigger than one might think, because lot of people 
move between the countries regularly - you can drive during the same day from 
being in NOK region to SEK region and further to using DKK. USD, EUR, NOK, SEK 
etc codes are therefore more readable.

Original comment by la...@playmysong.com on 10 Jul 2013 at 8:04

[GoogleCodeExporter]

why I can kind of understand why the display price comes down in the request 
but its rather useless for analytical purposes...This issue was reported a 
fairly long time ago. There is little to no excuse for intentional excluding 
the actual price from the response..unless there was some kind of plan to force 
people to use some sort of new API feature in google analytics. f that's the 
case..thats dirty..and something I would expect from another company..not 
Google. I certainly hope this gets resolved quickly

Original comment by siri...@breaktimestudios.com on 15 Jul 2013 at 5:24

[GoogleCodeExporter]

We have run into this problem also. Our app needs to be able to compare in-app 
purchase bundles by price in order perform certain functionality such as 
sorting bundles for display to the user and also for our own metrics gathering 
so we can understand what currencies our users are buying in and how much they 
are spending.

On iOS this was easy to do because in addition to the formatted price string, 
the API gave back a currency code and a decimal amount in that currency. On 
Android we just have the formatted string, which makes it pretty much 
impossible to extract much more meaningful information on the in-app purchase 
other than a display price.

Any update on a possible fix for this issue?

Original comment by darragh...@runbox.com on 27 Jul 2013 at 5:30

[GoogleCodeExporter]

We don't have an ETA to share at the moment, but we're working on it!

Original comment by b...@google.com on 29 Jul 2013 at 11:13

[GoogleCodeExporter]

That's great news! Thank you for the update.

Original comment by darragh...@runbox.com on 30 Jul 2013 at 4:23

[GoogleCodeExporter]

I understand that you are you are doing customer service for all of us 
complaining about this issue but if this issue was being worked on in any 
remote way it would have been done a long time ago. Could you provide some 
insight into what is actually happening with this beyond generic statements?.

I don't mean to come off rude in anyway here we are just evaluating whether or 
not to use or depend on this in the near future.

Thank you in advance for any kind of response

Original comment by siriele...@gmail.com on 30 Jul 2013 at 5:10

[GoogleCodeExporter]

I don't understand why a company like Google is taking so much to fix this 
trivial issue from programming standpoint ! Its not more than an hour fix that 
Google is taking more than 5 months just to evaluate !!

Original comment by ptyag...@gmail.com on 30 Jul 2013 at 5:42

[GoogleCodeExporter]

From an analytic standpoint, what kind of work flow requires this? Don't you 
already know pricing information from setting prices on the developer console 
and via the monthly sales reports? It also seems like you can do sorting on 
these price values in app by comparing the digits portion of the display string.

Original comment by scwee...@gmail.com on 30 Jul 2013 at 5:59

[GoogleCodeExporter]

@scweeden: as I understand it, one could in theory keep a local sku <=> price 
mapping (per supported currency?) in the app, and then use that price for 
analytics purposes. That could work for simple apps that never change prices, 
but as soon as you start changing prices or including new items, you would have 
to update that database on all the clients. So it's much easier if the API 
gives you price + currency separately in a machine-readable way.

Original comment by b...@google.com on 30 Jul 2013 at 6:44

[GoogleCodeExporter]

#37 and #38: please read through the thread. A mapping would be useful, if only 
this lame API would return *which currency a transaction was actually performed 
in*

It's amazing how this can still be overlooked. It's so blatantly ridiculous 
that I don't know if I should laugh or just cry at the incompetence of whoever 
makes decisions in the dev team. This service is extremely expensive compared 
to many others, for no obvious reason. Wouldn't it be fair to expect some basic 
functionality at the price of 30% of our in-app income?

I'm sick of waiting for a fix to this. Feels like Google just don't give a sh*t?

Original comment by martino...@gmail.com on 30 Jul 2013 at 11:15

[GoogleCodeExporter]

Looks like there's finally an update to the Play Store with two new fields in 
4.3.10.  AndroidPolice has the apk.  The data:

{"title":"RETAIL 3","price":"$3.33","type":"inapp","description":"RETAIL 
3","price_amount_micros":3330000,"price_currency_code":"USD","productId":"3"}

Original comment by mtt.mllns@gmail.com on 6 Aug 2013 at 5:42

[GoogleCodeExporter]

Thats interesting. Is the API updated as well? Seems there's no update to
the Google Play Billing Library yet?

Original comment by martino...@gmail.com on 7 Aug 2013 at 5:56

[GoogleCodeExporter]

API docs aren't updated but that's all that would change.  The "Library" is 
just the aidl interface.  Everything else lives in the Play Store apk.  
getSkuDetails() now returns more fields in the JSON blob than it used to.

Original comment by mtt.mllns@gmail.com on 7 Aug 2013 at 11:18

[GoogleCodeExporter]

Ok, that's great news! Thanx for the clarification.
/ Martin

Original comment by martino...@gmail.com on 8 Aug 2013 at 4:24

[GoogleCodeExporter]

Can someone explain what would it take for _every_ client to receive the new 
price_amount_micros, price_currency_code field??
The market app needs to update itself, right? Or is this generated server side?

Question is: when/how can I RELY these fields are there?

Original comment by gbat...@gmail.com on 8 Aug 2013 at 6:44

[GoogleCodeExporter]

Well, if the data comes from the customers' installed Google Play app, we
can not assume the fields are there unless google forces everyone to
upgrade (by not allowing purchases from older versions), which seems
unlikely in the short run.

In my experience some people just never upgrade (intentionally).

But there is of course a possibility that the GP service app just blindly
returns whatever the backend supplies, and in that case a backend upgrade
would instantly affect also older versions?!

I got an upgrade to the billing sdk today, that wasn't available (to me)
yesterday.
Den 8 aug 2013 08:44 skrev <marketbilling@googlecode.com>:

Original comment by martino...@gmail.com on 9 Aug 2013 at 10:11

[GoogleCodeExporter]

Wow, today I have received the two new product info fields including separated 
currency and price, here is an example product info:

{... "price":"$10.00", 
..."price_amount_micros":6440000,"price_currency_code":"GBP",....}

What I see here: price field is in local currency, and price_amount_micros and 
price_currency_code are in default merchant account currency.
Is this some kind of temporary failure, or is this thought this way?
non-local prices are pretty much useless. :-(

Original comment by gbat...@gmail.com on 9 Aug 2013 at 2:49

[GoogleCodeExporter]

@gbat Agreed, if the new fields are always in default merchant account currency 
then it is not what we wanted either. I hope that is not the final design.

I suppose if price_amount_micros was the actual local price converted at 
current exchange rate to merchant account currency it would have some value for 
analytics. Were you getting that, or was it just the GBP product price?

If google is listening though -- to be clear, it would be much better to simply 
get the local price in micros and currency code.

Original comment by m...@lootworks.com on 9 Aug 2013 at 4:11

[GoogleCodeExporter]

is there a way i can check to see if a user is using the new GP apk? 

Original comment by weist...@gmail.com on 9 Aug 2013 at 5:46

[GoogleCodeExporter]

Is there any way to test getSkuDetails with localized results. I mean, I'm in 
EuroZone, (Spain). So I guess, my WiFi, IPAddress, and probably credit card 
corresponds to EURO. Even I change the localization settings in my tablet, the 
results shown in my APP are EURO. I want to test our source code is working, in 
Dollars or whatever. So how to do this check?

Thanks.

Original comment by nospam...@gmail.com on 15 Aug 2013 at 7:09

[GoogleCodeExporter]

We need the price without formatting (a decimal number) and a locale identifier 
for formatting the price. Not a formatted string. Any update on this bug?

Original comment by zbowling@gmail.com on 22 Aug 2013 at 12:09