Software Glitch Leads To $23,148,855,308,184,500 Visa Charges 544
Hmmm2000 writes "Recently several Visa card holders were, um, overcharged for certain purchases, to the tune of $23,148,855,308,184,500.00 on a single charge. The company says it was due to a programming error, and that the problem has been corrected. What is interesting is that the amount charged actually reveals the type of programming error that caused the problem. 23,148,855,308,184,500.00 * 100 (I'm guessing this is how the number is actually stored) is 2314885530818450000. Convert 2314885530818450000 to hexadecimal, and you end up with 20 20 20 20 20 20 12 50. Most C/C++ programmers see the error now ... hex 20 is a space. So spaces were stuffed into a field where binary zero should have been."
The Aftereffect? (Score:1, Interesting)
If I remember correctly, my credit card bounces into "crap customer mode" when certain activity like overcharges (or nonpayment) occur. This ups my interest rate permanently from 6% to something silly like 20%.
If this happens, I wonder how many people will be relieved to have the charges reversed, only to be upset next month when their rate is hiked.
Illuminating answer on Stack Overflow (Score:2, Interesting)
It was probably partly overwritten by spaces [stackoverflow.com]
Re:meh (Score:5, Interesting)
Re:of course they didn't reverse interest charges. (Score:3, Interesting)
Seriously though the Visa transaction charge of 2% = 462,977,106,163,690
How could this transaction go through?
Re:Extremely speculative. (Score:3, Interesting)
Re:Only Notice Large Glitches (Score:5, Interesting)
32767 (Score:2, Interesting)
This reminds me of the time I transferred 100,000 miles from my Amex rewards account to one of my airline mileage accounts. I initiated the transfer on the Amex website. When I logged into the airline web site to confirm the transfer, I saw that it had been transferred in increments: ;)
32767,
32767,
32767,
and finally 1699
Re:At least it wasn't EBCDIC... I can see Starbuck (Score:1, Interesting)
Re:meh (Score:1, Interesting)
My father's a paranoid NRA type, and I couldn't agree more. I tell him all the time "you can always trade brass for gold, but you can't always trade gold for brass".
Re:meh (Score:4, Interesting)
Believe it or not, that was after Zimbabwe had lopped off a bunch of zeros from their currency the previous year.... twice. And then they did it a third time a month after they printed their first $100 trillion notes.
I was going to say something similar:-
On July 30, 2008, the Governor of the RBZ, Gideon Gono announced that the Zimbabwe dollar would be redenominated by removing 10 zeroes, with effect from August 1, 2008. ZWD10billion will become 1 dollar after the redenomination.
Then
[*After* the above revaluing] On 12 January 2009, Zimbabwe introduced the $50,000,000,000 note.
So you can multiply $50 billion by $10 billion (per new dollar) to get what it would have been if they hadn't done that sleight of hand; $500 billion billion.
Or let's put that another way (50 * 10^9) * (10 * 10^9) = 500 * 10^18 =
500 exadollars, or 5,000,000,000,000,000,000 dollars.
If 1,000,000 US dollars in 100 dollar bills weighs 10kg [answers.com], then assuming Zimbabwean 100 dollars had similar weight, the unrevalued currency would weigh:-
$5*(10^18) / ($100,000 per kilogram) = 5*(10^13) kilograms = 5*(10^10) metric tonnes....
i.e. 50 billion tonnes!!!
Re:meh (Score:5, Interesting)
Meanwhile, you're transferring the gold certificates around, complete with fees for every transaction (straight to the vault owner, naturally) and he still has an impervious vault full of gold. If society breaks down--which gold buyers seem to expect--you really think he'll honor those scraps of paper? No, he'll be riding it out inside the vault.
I'm too paranoid to buy gold, I invested in seed corn. Too large to steal, too real to lose value.
The United States is right behind him.. (Score:3, Interesting)
Since our national debit has just hit 1 trillion dollars, we in the United States of American will be second to him in debit.
I'm very surprised that credit card company, bank or anybody else didn't have any alarm bells (more air raid sirens in this case) when this went through. Also I thought there will be limit on anyone could charge, not only the credit card, bank or even this case, the nation could get.
This shows there is something wrong with the financial system and that is the understatement of the century.
Re:meh (Score:1, Interesting)
It's worth way more than the entire world's wealth combined...
The U.S. National Debt is only $60 some Trillion dollars, the entire world GDP is only $54 Trillion dollars...
You could buy the entire world with that kind of money........ lolol.
Re:Only Notice Large Glitches (Score:3, Interesting)
It sucks because the phone companies legally make money off of other people's fraud this way, so they have negative incentive to check the identity of the crammers.
Re:Extremely speculative. (Score:5, Interesting)
Re:Nothing to see here, keep moving along please.. (Score:3, Interesting)
I work in this industry. The only novelty here is that the error got into production, and was not caught and corrected before it went that far.
That explains why there are so many software testers currently looking for work. The CC industry doesn't use as many of them, anymore.
Some submitters do, from time to time, change their code, and sometimes they get it wrong. For instance padding a field with spaces instead of zeros. Woopsie...!
You're still using legacy zero padding? You should be doing things in XML.
Seems that's what happened here. Sounds like a hex or dec field got padded with hex 20, and boom.
Not quite. If it were padded with space characters, you get 0x20 in each byte (and that's just what this number had in the first 6 of 8 bytes). If it were padded with zero characters, you would get 34,723,282,962,276,803.04 or so.
The REAL problem here is that the code was interpreting 64 bits as internal binary integer, when the data that arrived was at least 6 ASCII space characters. In other words, the data was in an old legacy format with space padding (which is easily handled by decimal conversion code along with zero padding), but the code expected a raw 64 bit integer, perhaps in the big-endian byte order.
This is annoying, especially when the processor gets to help correct the overwhelming number of errors, and then tries to explain that it wasn't their fault. Plenty of blame to go around with this one.
It was clearly someone's fault. Possibly a programmer not applying the proper field conversion? Perhaps the code was intended field conversion in place (replace the memory that has ASCII digit characters with the binary representation) and the conversion bailed out for some reason and the calling code didn't properly detect that (hint: in today's dollar amounts, the highest order byte of 64 bit integers should be zero).
Even if a programmer is to blame, management is not blameless. And maybe it's not even a programmer to blame. Ultimately, the real blame does lie with management who should have seen to it that errors never happen. Of course, errors do happen and while the blame may be correct, it's really cheaper apply 99.999% perfection instead of 100% perfection. It's not that serious a blame ... at least as long as problems get corrected.
And then explains why they don't both validate/sanitize input, and test for at least some reasonable maximum value in the transaction amount. A max amount of $10,000,000 would have fixed this. That and an obvious lapse in testing. This is what keeps my bosses awake sometimes, fearing they will end up on the front page of the fishwrap looking stupid 'cause their overworked minions screwed something up, or didn't check, or didn't test very well. I love one of the guys we have testing. He's insufferable, and he catches genuine show-stoppers on a regular basis. They can't pay him what he's been worth, literally $millions, just in avoiding downtime and re-working code that went too far down the wrong path.
I don't know that $10,000,000 would be high enough. The kind of error this one is could be detected with a test against 2 to the 56th power. A lower test might catch other errors. And whatever tests are done, they should be in their own class, module, function, macro, or whatever, and separate from the mainline code. Two tests should be applied, one being conservatively high but fixed by the coders (e.g. the 2 to the 56th power test) and the other being configurable for code used by multiple processors (they can choose their own closer to the edge sanity check).
Believe me, this is in some ways preferable to getting files with one byte wrong that doesn't show up for a month, or sending the wrong data format (hex instead of packed binary or EBCDIC, for instance) and crashing the process completely. Plea
Re:Only Notice Large Glitches (Score:1, Interesting)
Years ago our phone company began mis-charging us. We called and had it fixed a couple of times. Once it became apparent that they didn't care to fix the underlying problem we told them we wouldn't pay until they sent a correct bill, incorrect bills wouldn't be paid.
Apparently paying someone to manually correct all our bills was too expensive, so they told us to "strike anything we didn't want to pay". We sent them back bills struck through entirely, and they happily accepted zero payment for months until they got their act together and fixed the billing system.
Re:What is truly appalling... (Score:2, Interesting)
TFA mentions that the over-limit charges were waived but did they reverse the charge in a way that won't affect his average daily balance? Or will he be facing a 15 trillion dollar finance charge on his next statement?