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.

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!

Comment deleted

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

"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.

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.

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

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.

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.

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.

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

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

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

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

Comment deleted

Comment deleted

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.

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.

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...

Hope they get this fixed in next release !

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?

Comment deleted

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).

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?

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.

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

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?

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

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

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.

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.

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

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?

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

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

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

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 !!

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.

@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.

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?

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"}

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

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.

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

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?

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 :

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. :-(

@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.

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

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.

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?

Comment deleted

49 @nospamx24 : To test in other currency you must change the Billing address in your Credit cards in Google Wallet to the one that you want to see in your test.

Probably the bug is still not fixed, because I also receive different prices (RUB/USD): {... "price":"31,38 руб.","price_currency_code":"USD","price_amount_micros":990000, ...}

the price is NOT the actual price which user would be paying for that IAP. it is the list price from the seller's account. Please provide the localized currency code and amount. I dont understand why I can get the accurate price back from google play store but NOT with the getSKUDetail api. This is not good. Please fix this as soon as possible.

I'm really curious whether guys from In App Billing ever read this: https://developers.google.com/analytics/devguides/collection/android/v3/ecommerce?hl=en#implementation

You are the same company but connect meaningfully your two (very closely related) services is almost impossible.

So what is the verdict? will "price_currency_code" and "price_amount_micros" reflect the currency that the user submits the payment in? This is the desired behavior for me. The currency that the price was set in is fairly worthless-- I know that already!

Another easy way to solve this would be to just add the data we need, to the Google Play Purchase API responses... Hello Google?! Hire me for an hour or two or do whatever you have to do to fix this stupid flaw.

/ Martin

Question: In my app this might not be a huge problem (though it will mess up my statistics!). I want to print the price of the item in the local currency, but for various reasons I can't print unicode characters. Will the getSkuDetails() "price" entry ever return Unicode? For example, how will the Euro symbol appear?

Can we get another official status update on this? It's been months...

As mentioned above in the thread, two new keys are now showing up in the sku details (price_currency_code and price_amount_micros) which seems to be getting at what we're asking for here. But the usefulness hinges on the values being returned in the actual currency that the transaction would take place in which apparently is not the case.

Bueller? Bueller?

One year after the first report, is there still no solution to retrieve the amount and the currency of the transaction ?

We are in desperate need for this feature for security purposes on our app and cannot release until this feature has been added. Whats going on here?

Any update or ETA on this ?

This issue is over a year old and still not fix :( and no ETA?

Comment deleted

It seems a bit strange that there is no method to get the standard currency-code for my in-app purchase items (like USD,CAD etc.) while the PlayStore dialog has that info when the user has to proceed to payment.

Any news on this? It would be really useful to get this data, same thing we are getting right now but with an extra currency_code attribute

I've been on this thread for more than a year, I don't believe anyone from Google has ever commented and obviously the issue is not fixed.

I have a serious question (not being sarcastic) -- does anyone know if this site is actually used by Google? My impression is Android's support staff pay more attention to stackoverflow.

This is sad! There is still no ETA!

This functionality is imperative for proper revenue tracking. Please adjust the Priority to High. Anybody who needs this functionality, please comment wrt priority for your need.

Piling on with Peter. We process many millions in international revenue. Millions of WHAT? Good question and one we can't answer reliably due to this shortcoming.

I'm speechless. Sorry everyone, tbh, it seems they just won't fix it...?!

It's is of course a serious crime not to be able to do the book-keeping properly. We can neither calculate VAT figures, nor revenue etc and Google is just blatantly ignoring this fact!

I guess in the end the tax authorities will prohibit the use of Google In-App Payments for sales (or possibly prosecute Google for forcing us into this by being the largest app market and allowing their own "solution" only?)

HIGH PRIORITY IS URGED THIS ISSUE MUST BE FIXED IMMEDIATELY

Comment deleted

Comment deleted

Well, 'price_currency_code' and 'price_amount_micros' were mentioned in this thread before, around Dec 2013: It turned out they did NOT give us the values we need, because the implementation (at that time) only gave us the price and currency of the merchant account, which is basically meaningless information (since we already know what prices we gave our products though the dev console). The real issue is that the system don't (didn't?) give us the information about what has actually been charged from the end-customers, i.e. the price and currency localized to them.

I got confirmed last week from a contact within Google that the awaited functionality does not exist yet. It also doesn't seem very likely they would suddenly change the behavior of a method using the same keys as before, but I would be happy to be proven wrong.

2014-08-18 18:04 GMT+02:00 :

http://developer.android.com/google/play/billing/billing_reference.html#getSkuDetails

'price_currency_code' and 'price_amount_micros' has been added in this document. Dose it work?

It works! After all this time...

I have tested it myself and confirmed that it works! :)

Please see above comments. It sounds like the price_currency_code and price_amount_micros fields only return information on the currency set by the merchant account, not the actual currency of the transaction.

Reply to #77:

I have read those comments and have tested it myself with multiple currencies and have confirmed that prices are no longer only returned in the currency set by the merchant account. The price is now returned in the currency of the actual transaction.

That's some good news! I'm very happy to read your confirmations, but I guess I need to see it with my own eyes to truly believe it.. ;) I'll get back when I've had tested it thoroughly myself.

Have a great weekend everybody.

2014-08-22 17:34 GMT+02:00 :

Comment deleted

So while it's great that we have this new field it doesn't solve the problem of validations. If we are comparing prices assigned on a company server to the google prices to detect invalid products then this would cause failures in every user that doesn't use the same currency as the native currency of the developers, in my case US dollar.

Am I correct in understanding that this "price_amount_micros" will return a number who's value is the same currency as the user's wallet?

To #81, I've noticed that the "double" type values provided in SKUDetails refer only to the non-localized price set in Google Play, i.e. the one with the "Default price" label in the "In-app Products" section in the Google Play console. So, for these numeric (double) values, the values in the "Local prices" list are ignored, which are the ones the users will see from their Google Wallet service...

@#82 Thank you! I was worried that we price validation wasn't going to work with out of merchant currency. Saved me a lot of headache :)

This issue has been reported as officially fixed by the Play team.