Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Doesn't surprise me in the slightest.

Worked for a fintech company a few years back that used Wirecard as the processor for one of their products. Somehow they managed to lose the PK/FK relationship between accounts and transactions (or something like that). A whole lot of our customers suddenly started getting other people's transactions on their accounts. It was the final straw that shutdown the entire product line and we moved on to other providers for new projects.

So, not at all surprised they don't know where their money is.



So basically the cardinal sin of payment processing then? Not that I'm surprised.


I say cardinal sin would have been not storing amounts as integer.


(googler, opinion my own)

Just go give 2 ways of doing money storage in ints from Google's APIs...

For Google's Standard Payments APIs, we use micros: https://developers.google.com/standard-payments/v1/fops/bank...

> To represent a monetary value in micros, multiply the standard currency value by 1,000,000.

> USD$1.23 = 1230000 micro USD

Sadly, its different than other parts of Google with money/amount based APIs. GCP uses units + nanos: https://cloud.google.com/billing/v1/how-tos/catalog-api

> [UNITS] is the whole units of the amount. For example if currencyCode is "USD", then 1 unit is one US dollar.

> [NANOS] is the number of nano (10^-9) units of the amount. The value must be between -999,999,999 and +999,999,999 inclusive. If units is positive, nanos must be positive or zero. If units is zero, nanos can be positive, zero, or negative. If units is negative, nanos must be negative or zero. For example $-1.75 is represented as units=-1 and nanos=-750,000,000.


From reading other comments it seems that "micros" aren't precise enough to represent one satoshi if the unit is whole bitcoin.


There's a cardinal pun somewhere in there but I can't think of it.


Bird, position in the Catholic hierarchy, countability, or direction wise?

Something to do with using floats to indicate cardinality briefly plummeted, but was summarily dismissed.

Regardless, losing track of the numbers to accounts reminded me of this one place I worked where the transaction geese weren't recorded as explicit callouts on the transaction ledger, but rather had to be cross-referenced with final transaction amounts and the fee configuration for time period, but where the changing of fee configurations were not tracked with a granularity sufficient for resolving all ambiguity come audit time.

And I thought that was bad.


... but I can't place it.


This would be a top tier joke if only we could rank it.


No losing the user-to-number relation is way worse than a bad number representation.


Just curious, how would you manage bitcoin fractional shares.


Bitcoins are represented as integers. A whole Bitcoin is 100MM satoshis.

Typedef int64_t CAmount;

Static const CAmount COIN = 100000000;

Static const CAmount MAX_MONEY = 21000000 * COIN;

https://github.com/bitcoin/bitcoin/tree/master/src/amount.h


Why would you need fractional bitcoin shares? The smallest unit of bitcoin isn't 1 bitcoin (like with stocks), it's 1 satoshi or 0.00000001 bitcoin.


Arbitrary precision arithmetic.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: