0

I'm currently doing an application design that involves sale of service. The application will ultimately be used internationally and will need to adjust prices based on user location.

Is it a good idea to store / work with all prices in an absolute unit? For example - credits. And I can specify conversion rules like 1 credit = 1 USD. What scenarios would I need to be careful about if I do this (and should I be doing this)?

One thing I can think of is problems during auditing if I change my conversion rules periodically. In which case I'll need to start storing conversion rules by date and the conversion process will also require the time of transaction to give the correct amount in any currency for that time.

Am I complicating this too much?

  • At the most basic level you would require a currency class. This class would determine all behavior dealing with currency. Of course Phoshi raises a good point, having your own virtual digital currency does not make it simple, and the best solution is often the K.I.S.S solution. In either direction when dealing with currency you should follow the best industry standard, make sure you take into account rounding errors, thousands of 0.00001 transactions is a serious rounding error. – Ramhound Dec 4 '13 at 15:32
5

You're both over and under-complicating it. You're over-complicating it for the users, who now have to convert things between credits and their local currency in their head, and under-complicating it for yourself. Things are not priced identically around the world, even once you account for exchange rates. Heck, things are not priced identically around what I assume is your home country of the US, tax rates change on a per-state and per-city level and for a payment system this has to be taken into account.

Simply put, this will increase the difficulty for the user (and thus decrease the likelihood they'll actually give you that money) and not significantly improve your own situation. Systems of "points" instead of real currency are typically used not to simplify things, but to hide the true cost of items, and only really work well in situations where there can be no competition. See theme parks, proprietary video game systems, casinos, et cetera.

| improve this answer | |
  • I don't plan to have users select their currency. There will be a locale layer on top of the application that shows only one price to the user (the one in their currency) – n a Dec 4 '13 at 11:16
  • 6
    "Things are not priced identically around the world, even once you account for exchange rates." - this is what I was looking for. Makes sense now. – n a Dec 4 '13 at 11:17
  • Indeed, there's an entire field of economic activity structured around exploiting these pricing differences - "arbitrage" -and it's really big money. – Ross Patterson Dec 4 '13 at 11:38
2

I don't think you can do this with an artificial currency.

At some point your application needs to interact with the "real" world of accounting, and the transactions need to be auditable ... in terms of an actual currency. The tax man wants his cut of the action ... in a particular currency. And people need to pay definite amount of money in real currencies.

The simplest way to do this is to nominate your prices in specific currencies ... and let PayPal or the Credit Card company ... or the customer's bank deal with the problem of converting the customer's money to the currency you require payment in.

(And note that if you accept payment in multiple currencies, you will end up paying for the currency conversions rather than the customer!)

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.