Is 23,148,855,308,184,500 a magic number, or sheer chance?
Add the cents to the number and you get 2314885530818450000, which in hexadecimal is 2020 2020 2020 1250.
Do you see the pattern? The first six bytes have been overwritten by spaces (hex 20, dec 32).
Hold on a second; there’s something fishy going on.
While the space-padded explanation certainly seems good, it may be (at least partly) specious.
VISA said that there were “fewer than 13,000” customers affected by the snafu with the Visa Buxx pre-paid cards. I’ve found news on several so far. Josh Muszynski in New Hampshire, Jason Bryan in Tennessee, Ron Seale in Texas, Karen Taylor’s teenage son in Bethel, and a teenage girl, Elizabeth Lewis in Owatonna .
The thing is that all of them have the exact same charge: $23,148,855,308,184,500.00. If the problem was the space-padding, then how is it that all of them had the exact same $0x1250 ($46.88) charge? Two of them had purchased cigarettes at gas stations, another two had paid at restaurants, Lewis bought eggs and milk, the last one at a drug store. Do all these varied items happen to cost the same? $46.88 for a restaurant bill seems okay, but for a pack of cigarettes? for milk and eggs‽
The space-padding error makes sense, except it does not account for the 0x1250 constant. Why is it that all of them ended up with 0x2020 2020 2020 1250 instead of 0x2020 2020 2020 2020 or different numbers in the last WORD?
Hmmm, if only 13,000 customers were affected, it may be that somehow that exact, specific charge triggered the error. In that case, it is more than just a field error. If it was just the text field being interpreted as a 64-bit integer, then why didn’t other amounts cause it, thus affecting everyone, not just <13,000. Still, how is it that 13,000 people could have just happened to charge the exact same amount in the same week?
They say it’s a “temporary programming error”, and it may well be, but could it be a hacking thing? In that case, it probably would be a magic-number. In fact, it may be a combination of both: some hacker putting a 0x1250 automatic charge, that got combined with the space-padding error, causing one or both errors to be detected.
The Register thinks that the answer is indeed the padded-field error, but does not expand on why they are all the same, although one of the comments mentions the number possibly being rounded to the nearest $100 (unlikely since banks and banking software explicitly go to lengths to ensure precision).
(There is also a report of a similar, earlier error.)
Jason Bryant’s bill:
Elizabeth Lewis’s bill:
Ron Seale’s bill:
Josh Muszynski’s bill:
What happens when you make a purchase by card is that the software immediately goes online to ensure you have sufficient funds for the purchase, but only places a hold on the funds for the transaction. At the end of the working day the software then gathers all the transactions placed in the last 24hrs and submits them to the acquiring bank for processing.
The submission to the bank is known as settlement, and its done by sending a plain text file in a very rigid format. (This was all developed decades ago and the number of systems now using it makes it hard to modernise)
Each transaction appears in the file as a line of text, and part of that is the transaction value. This field should be 11 numeric characters (zero padded on the left hand side) and will always hold the value in lowest common denominator (in this case cents). 11 numeric characters caters well for values in any currency.
Looks like the payment processor in this case had made some changes to their submission software and erroneously replaced the zero padding with space padding. Quite how this got by a) service provider, b) acquiring bank and c) Visa without being picked up escapes me. The net value of that settlement file (13,000 high value transactions) would have been astronomical, and maybe that also was a contributing factor somewhere.