1

I have an architecture front-end / back-end, specifically an Android app and a backend. I want that the app user can see different prices and currencies depending on their geo-localization. So my Android app has a mechanism to know in which country the user is (based on geo-localization), then it queries the backend using ISO 3 country (GBR) and the backend returns a price (say 5.00). Then I need to get the currency (£) based on the country. The above mechanism is not neat and elegant but it does the job. The problem here is that every client (Android, iOS, Web app, etc), needs to implement the mechanism, while it seems easier if it was the backend to implement it once.

Possible solutions:

  1. FE queries the BE by ISO 3 country, BE returns a string containing price and currency (£ 5.00, 7.50 €), handling also the different position of the currency symbol
  2. FE queries the BE by latitude/longitude, then same as above.

What are the pros/cons here?

Christophe
  • 74,672
  • 10
  • 115
  • 187
peval27
  • 119
  • 1
  • 6
  • I would favor a backend solution, if you want exact price according to the current money rate, it would be easier to have a backend getting those informations on the net and translate price on the fly. Note that geolocalisation isn't really going to change, it could just be a user's parameter which default value is determined first from geolocalisation (like we do with classic locales). – Walfrat May 30 '17 at 12:55
  • @Walfrat ok. better to return the formatted price with its currency then? – peval27 May 30 '17 at 13:04
  • For me the symbol of currency would be stored in session, so you would only have the price to return but it's not that much important. I would favor to return an object with the raw price and it's associated unit over an already formatted price, letting the client side formatting that for me. So my backend would returns raw data only. – Walfrat May 30 '17 at 13:15
  • 1
    Using latitude/longitude might not always be accurate. Especially in border regions, or very small areas (like St Pierre and Miquelon use the euro, but by lat/long, they *look* like they should use the Canadian dollar), or when borders change (and they will do that as well), or are contested (and you offend one group by making them use the currency that they don't think they should). – FrustratedWithFormsDesigner May 30 '17 at 14:15
  • What is the goal of location specific properties? do you need high accuracy location (i.e. show higher prices if there are no competitors around)? what is the usecase where os-specific settings (language, currency, date-format, time-zone) is not enough? – k3b May 31 '17 at 07:21
  • @k3b I need to show a price for that specific country. It's not only the original price divided/multiplied by the exchange rate, but a totally different country. You may want the customer to pay 5€ in Germany and 4.5€ in France. We can't use OS specific settings because: 1. If I am abroad for 1 month, I want to pay the country-specific price (and not the price of my country); 2. there are people who use English locale outside of UK/US/etc, for example in Germany. – peval27 May 31 '17 at 11:24

2 Answers2

5

On the technical side:

Querrying the backend using the longitude and latitude (option 2) has the advantage of providing the country in the same way for every platform.

However it has the following drawbacks:

  • a user can refuse to share geolocalisation in order to protect his privacy. You won't get lattitude and longitude. THis will break your design.
  • whenever a user refuses geolocalisation, you're bound to the phone configuration, which will certainly determine country using less accurate means (e.g. phone configuration, IP address, telecom carrier, etc..). So if you implement option 2, you'll anyway have to provide for option 1.
  • this design does not enforce privacy by design, because you involuntarily track the movements of the user on the backend, whereas it's not directly needed to provide the service you intend.
  • geospatial coordinates are not completely accurate in some areas, or if you're in tunnels or undergrounds
  • geospatial coordinates might be irrelevant if user sits in a train or a plane
  • In addition you might soon worry about legal issues as well: it is not to exclude that some countries could adopt laws to restrict geotracking. Especially if more incidents like this one raises awareness and fears.

So for all these reasons, I'd strongly suggest option 1 and pass the country code to the backend.

The user experience point of view

Using geographic location to decide on localization topics such as number and date format does not always give you happy users. Here some topics you should consider:

  • Some peope could consult your site while on travel. They may want to use the formatting of their home country and not one which they are not familiar with.
  • For currency it's even worse: it's possible that the user want to see the prices in local currency of the shop. Or they may want to see the prices in their home currency (because they are on business trip and will handle the order when back at home).
  • Some countries have several official languages: minorities might get upset if you systematically use the most used language. SO for language, best get the preferences from the phone's or the browser's settings.

So if you use a geolocalized country code, consider to nevertheless take the localization settings from the phone (language, formats). And if you use local currency of the country (especially if your app is related to tourism), give your user the possibility to change the display currency.

Christophe
  • 74,672
  • 10
  • 115
  • 187
0

For some reason your clients have a luxury to make decision on which currency to use. It would be better if decision on such sensitive setting will be done by server.

Let your server accept locale, coordinates, user selection and whatever else from client during session initialization, sanitize them and return currency to client as one of the session settings. Client will just take care about rendering.

Allowing client to make such decision

  • Opens attack vectors via currency spoofing.
  • Removes any control from currency selection process and ability to adjust it fast on server side.
  • Forces you not to be DRY implementing currency selection on each platform separately.
  • Requires a bit more traffic and processing power on client side.
Vlad
  • 559
  • 1
  • 3
  • 6