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:

https://i.stack.imgur.com/iJsz0.jpg

Elizabeth Lewis’s bill:

https://i.stack.imgur.com/vZKKt.png

Ron Seale’s bill:

https://i.stack.imgur.com/XHzRa.jpg

Josh Muszynski’s bill:

https://i.stack.imgur.com/XvqvL.jpg

---

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.

---

If you remove the trailing zero, this validates as a VISA card number. My guess is they swiped the card then manually entered the number, thinking the swipe had failed.

---

The ultimate mystery is still where 12 50 is coming from. They are the ASCII codes for Ctrl+R, P. Which happens to be the secret keystrokes you have to type to enter the validation code for QuickBooks.

Link: Where to enter Validation code

Quite a coincidence. I wonder what happens when you type these keys in the wrong place...

---

If you shift left 64-bit representation 8 bits left (multiply by 256) You will get a well formed credit card number and 3 empty positions for thise 3 secure extra numbers (all zeroes for some reason). There is only 1 out of 10 chance that random number gives a well formed CC number.

5926 1069 5889 5232 000

---

If you use the binary equivelant (1110101110110100) decode of the number 23148855308184500, you get K鑛, which is the Mandarin character for mining and ore. Kmine could mean "knowledge mine," or something like kmine Holdings Ltd. Perhaps there's a correlation between K(mine or ore) and Bank of America or Visa?

---