When working with money in an application, ensuring everything is accounted for is important.
In this post, we will explore some common methods and best practices of handling money in your Ruby app, and see how you can use money-rails
to write maintainable money-handling code.
Let's get started!
Use Cases for Storing Money
There are several use cases where your Ruby app might need to handle money — for example, an e-commerce company that sells products, a SaaS maintaining users' subscriptions, etc.
In this post, we will walk through some examples of how to handle money in an e-commerce app.
Storing Money in a Ruby Database
First, let’s start with strategies for storing money in your database: using a float column, the numeric
type, and the integer
type.
Using a Float Column
The most obvious way to store money is to use a float column. However, because of the way floating-point numbers are stored, they do not guarantee exactness. Instead, they only approximate the actual value. While this might be sufficient for some applications, there are much better ways to store money.
Using the numeric
Type
The numeric
type can store arbitrary-precision numbers in a database.
A numeric column can store a large range of numbers (up to 131,072 digits before a decimal point and up to 16,383 digits after a decimal point) and is therefore perfectly suited to work with money.
But one important point to note here is that calculations on numeric types are very slow compared to integer/floating-point numbers.
Numeric types should be the go-to data type when you need arbitrary-precision numbers, but, depending on business logic, they are rarely needed unless it's for very specific use cases. Let’s see if we can do better in an e-commerce scenario.
Using the integer
Type
We need to store the prices of products, with the lowest unit being cents.
A product can be priced at $19.99
but never $19.9954321
.
This means that, instead of working at the dollar level, we will always have an integer value as the price at the cents level.
We can easily store an integer without any approximation in the database using one of the integer types (e.g., smallint
, integer
, bigint
).
But please note that this does constrain the represented values (as compared to the numeric
type) — the maximum integer
value on Postgres 2147483647
will be $21,474,836.47
.
This should normally be enough for any e-commerce product, but it’s good to know that there’s a limit.
If you require higher precision (for example, a 10th of a cent), this is possible by just storing the amount as a mill instead of cents.
Keep in mind that this will further decrease the range of values that can be represented in an integer column.
But an integer
's big advantage over a numeric
type is that calculations are very fast.
As long as you can work within the integer (or bigint
) range and have clear constraints set, using an integer
/bigint
is the recommended storage option.
Sorting out storage is just the first step to representing money in our Ruby application, though.
You might also need to handle different currencies, formatting the values based on the location of users (e.g., USD is formatted as $1,234.56
, whereas the same amount in Euros is formatted as €1.234,56
).
While it is possible to implement this manually, a gem like money-rails
can handle it out of the box for you.
Enter money-rails
for Ruby on Rails
Money-Rails integrates the money
gem in Rails.
It can handle automatic conversion between the database representation of money to Money
instances. These instances can then be used to access all helpers available from the money
gem (we will get to an overview of those helpers later in this post).
Additionally, money-rails
also has helpers for migrations and configurable validation options.
Let’s start by creating a product with a price.
We'll use the monetize helper to do that:
t.monetize :price
adds price_cents
and price_currency
columns to the table.
In addition to this, we need to mark the price_cents
column that money-rails
will control in the model.
With just a few lines, we now have access to a lot of helpers.
We can create a new product by simply passing a price attribute.
The price
will automatically be converted to a cent value for the database. When accessing the price
later, we will have instances of Money
.
You can also pass the attributes directly:
Currency in the money
Gem for Ruby
Currencies are consistently represented as instances of Money::Currency
.
This not only includes the name of the currency, but a lot of additional information like the name, symbol, iso code, etc.:
Check out the money
gem's currency documentation.
Let's say you only have a single currency in your application and don’t need to track currency inside your database.
First, set a default currency for money
in an initializer:
In the migration, disable the currency column:
There are many other Money-Rails migration helpers that allow null values for amounts or configure default amounts/currencies.
Validations with monetize
You can configure validations on money using the monetize
Active Record helper.
To do this, update your model to opt in for validations:
Now, if you try to save a product with an invalid price, validation will fail:
Localization
Money can be configured to either use the location information provided by i18n
or to localize based on the amount’s currency.
Use the locale_backend
to configure this — usually in an initializer like this:
In the above example, we set it to :currency
. This uses the formatting rules defined for each currency:
To configure a consistently formatted amount regardless of the amount’s currency, use the :i18n
locale backend:
When using the locale backend i18n
, it is also possible to configure the formatting using the translation files:
Note that if you are using rails-i18n
, configuration is automatically available for many locales.
Computations
Money instances are usable as regular numerical values with all operators, so you can compare values and perform arithmetic operations (using +
, -
, *
, /
).
This makes it much more intuitive to perform operations on objects containing money.
Since mathematical operators work as expected, you can easily compute sum/average or price discounts.
If you need to access the underlying value from a Money instance, you can do that using amount
or cents
:
Currency Exchange
If you are working with multiple currencies, you can automatically convert two different currencies based on exchange rates using exchange rate stores.
The default implementation is just an in-memory store.
It stores the exchange rates you provide using Money.add_rate
.
To use it, first add a rate. Then, you can use the exchange_to
method to convert a money object to another currency.
If a conversion rate is not present, it raises a Money::Bank::UnknownRate
exception.
So, if you are using this in production, you must provide the exchange rate before you perform any conversions.
You can provide a custom exchange rate store to handle this automatically. There are also some exchange rate implementations already available as gems.
For example, you can drop in the eu_central_bank
exchange rate store to fetch the latest exchange rates from the European Central Bank.
Once the gem is installed, you can set it as the default bank in the initializer:
Once set up, you can simply exchange any currency, and it should work:
Wrap Up
In this post, we saw how to store and work with money in a Rails application.
Money-Rails greatly simplifies the whole process and provides helper methods that make working with money safer and more maintainable in the long run.
Many other options are available to customize this for your Ruby on Rails app.
Check out the full details in the money
and money-rails
guides.
Happy coding!
P.S. If you'd like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!