Hey guyz
We at @aviabird are working on a payment library in elixir/phoenix. We are targeting March 2018 to add 56 Gateways to it.
Have a look at it in development here https://github.com/aviabird/gringotts.
Thanks
21 Likes
I had a quick look at the library. I think this is an awesome project and something very needed in the community. I have some some remarks, though.
Why are floats used for money? This is a complete no-go for me since floating point arithmetic is inherently inacurate. I haven’t looked in depth if this is actually the case, but that’s what is presented in the examples.
Why is the project using GenServers in the middle? It should be perfectly enough to have “just” modules and functions. The worker process does not use the state in any way, so the only thing it does, is creating a bottleneck in the system.
16 Likes
Yup - decimals or integers.
Also worth checking out this post.
8 Likes
There are a few libs that provide Money functions. money, ex_money and monetized (the first 3 on hex.pm) each seem to represent Money as a struct with a currency which is an ISO 4217 code and amount which is a Decimal.
It would be useful if Gringotts could support an abstraction for money types so that integration would be straight forward given than there’s a reasonable likelihood that someone using Gringotts is probably also using a Money lib. Maybe a Money protocol?
(disclaimer: I’m the author or ex_money)
11 Likes
I’ll just “upvote” this, because if this library is going to use floats internally it will be unreliable. The simplest way is to just use integers and have everything in “cents”, not “dollars” (that is if you don’t need to support currencies like the old pounds divisions in UK Understanding old British money - pounds, shillings and pence).
4 Likes
What parts of the payment gateways are you targeting? Is it just plain payments or are you attempting to support Hosted Payment Pages, subscriptions, refunds, betting? Do you have a list of gateways your looking to support or some kind of roadmap?
Just noting even “cents” needs care since an implied decimal place of fixed size (cents == 100) is also problematic for the 52 currencies that have no decimal places, the 6 that have 3 decimal places and the one that has 4 decimal places.
10 Likes
I had no idea such currencies exist 
3 Likes
3 decimal places: Libyan dinar, Bahraini Dinar and Omani rial
4 decimal places: Chilean unit of account (UF) which is a legal tender (https://en.wikipedia.org/wiki/Unidad_de_Fomento)
Money stuff is fun! 
7 Likes
And all those digital or cryptocurrencies? Don’t they have 6 and more decimals?
1 Like
ISO 4217 will probably take quite a while to catch up with those
Either way, assumptions about money need care - including the assumption of how many decimal places a given currency may have. Even ISO 4217 allows the creation of private-use codes and they can have whatever digits and rounding strategy you want.
1 Like
…the 6 that have 3 decimal places and the one that has 4 decimal places.
I had no idea such currencies exist
And obviously neither does anyone proposing to deal with money by
reducing all amounts to integers 
Using integers is perfectly fine for most currencies when decimal isn’t an option - at least from everything I’ve read about it.
What would you suggest if decimal wasn’t an option?
No I didn’t 
But I think that every currency has to by strongly typed, and have not only it’s value but also a mean to distinguish it from other currencies, so the conversion from the internal representation i.e. integers to an external representation does really rely on its type (is it US Dollar, Libyan dinar, Chilean unit of account, or rather something even more exotic for the majority of library users). Representing value internally by decimal type, can lead to nasty undesirable state, like having a 1.005 value for currencies that does not have 3rd digit in fractions. On the other hand we wouldn’t want automatic rounding…
Counting money is hard, maybe not as hard as dealing with time, but still…
1 Like
Using integers is perfectly fine for most currencies when decimal isn’t an
option - at least from everything I’ve read about it.
Not in my opinion – you will always have to deal with fractional
values and rounding at some point.
2 Likes
I believe that when dealing with money it’s important to
-
Always have a currency associated with any amount. Assumptions lead to issues including but not limited to rounding and arithmetic. Indeed some currencies round differently for cash values versus accounting values (for example the Australian dollar has a minimum 5c unit for cash and 1c for accounting/electronic transactions).
-
The value needs to be either a Decimal (fixed point) or an integer plus an exponent (which is how the Decimal lib works anyway).
In Postgres you can represent these opinions with a composite type (which is what I do in https://hex.pm/packages/ex_money) which Ecto supports out-of-the-box. For MySql its a bit trickier and I use a json field with the decimal amount serialised as a string value to preserve precision.
6 Likes
Thanks for the replies all… I’m glad I only had to think about pound sterling when I was working on an app that dealt with money (we used decimal)
1 Like
Yeah, we were looking for such library, but could not found one. So thought to give it a try. Thanks to the team effort we reached this stage.
Floats: - Oh that was really a great remark, Thanks. we can use some thing like money, ex_money and monetized suggested by kip , that are using decimal as the amount.
we are also thinking about adding a cryptocurrency gateway here. Then decimal would be the ideal solution for it. Will think about this.
Genserver: - We are still thinking about, giving the control to the end user or keeping the control to us, in relation to handling multiple requests like subscriptions in workers. Not sure right now. Since we are focusing on adding minimal gateways(6) first. So this time would be great to think about the supervision tree incase it is required or not, or just modules and functions will do.
Since the project is just some weeks old. Things/thoughts will come. Wanted to share it with you guys. Suggestions like these are the way to make a great library.
1 Like
Thanks for the suggestion. We really need an abstraction here for money types.
Awesome, you are the author of ex_money.
we are thinking of adding support for subscription and refunds too. Looking for community response regarding this.
we will be adding a road map on readme. Currently we are following Active Merchant strategy and gateways it provides.
