❔ Anyone got any advice on how to handle currencies in ecommerce/hotel booking?
I don't know if it's as straight-forward as it seems, but I'd appreciate any advice from people who've actually worked with this.
By the way, I'll preface by saying that currency is not of utmost important outside of displaying prices accurately, because payment is only done in person (as of this moment).
So, my initial thought was to do something like this:
When a host registers a property/accommodation, he might enter the price in his local/preferred/selected currency, and then I'll store it in an implied base currency (let's say EUR) at the current conversion rate.
Now, this seems pretty straight-forward. But what about conversions for displaying accurate prices? My initial thought was that this should be the frontends concern. The flow seemed more intuitive like this:
Website user/guest selects preferred currency, it's stored locally, and then either
a) all prices (EUR base price) are converted on the frontend to this currency (for displaying accurate prices)
b) or whenever a price-related endpoint is fetched, the preferred currency is also passed in and all the prices go through a conversion engine and then are passed back to the frontend in that currency (and maybe along with the base currency too for more accuracy).
Is this remotely close to what should happen? It seems relatively straight-forward if that's the case.
Which option is better? Pass in selected currency + conversion on backend or simply convert visually on the frontend?
18 Replies
store the actual registered value+currency, convert in backend, using a local cache of prices that you update every x minutes, hopefully fetched from the same place your payment API uses.
bonus points if when hovering over price in frontend (the converted price, that is) you get a small tooltip that shows the actual currency, value and current conversion rate
if you don't store in registered value+currency, you wont be able to guarantee the "provider" that they will actually be paid what they asked for, which imho is a dealbreaker
you'll need to figure out how to pay the payment providers cut + currency exchange cut + YOUR cut, and who pays it (ie, is it estimated and added on top of requested price, or do hotels/providers register properties before cuts are taken)
@Pobiegaby registered value + currency, do you mean that if they register it as 600 SEK, it should be persisted as 600 SEK in the database? and then a conversion should be on that (registered) currency every time?
imho, yes.
if you convert to say EUR, you can't guarantee that you would pay them 600 SEK when the property is actually rented/sold/whatever
because of how rates change over time
So what do you think about this?
>User selects location of their property
>Frontend detects local currency > prompts the user to enter price in that currency
>Backend uses this location/local currency when registering the price
@Pobiega
kinda? I'd suggest letting the owner/user set their preferred currency
maybe I want to be paid in EUR even if I'm browsing from sweden
maybe Im german
True
and also, perhaps your system can't handle all currencies
so you'd want a list of supported currencies anyways
True, I'll probably let them select from a handful of currencies
^
initially at least
and expand on that later
don't need to be airbnb on day 1 lol
ofc 🙂
@Pobiegabtw with regards to the currency conversion cache, do you mean to use something like redis and a task scheduler? like quartz maybe
something like that. doesnt need to be redis if this is a monolith
can just use IMemoryCache
I don't think this object will be very large.
@PobiegaAlright!" one more question, when you say "using a local cache of prices that you update every x minutes", do you mean actual prices of all accommodations and not conversion rates (against a base currency)?
or even store the conversion rate of every currency against every other selectable currency
conversions
yeah ok. think i've worked out how to do it. Btw, i should store the currency as enum in the db right and not string due to type safety?
@Pobiega
enum would be good ya
Was this issue resolved? If so, run
/close - otherwise I will mark this as stale and this post will be archived until there is new activity.