STORM2K

Kids these days! Hawkins writes, "My lectures about financial responsibility appear to have failed: yesterday [my teenaged daughter] charged $23,148,855,308,184,500.00 at the drug store." You would think Visa would have caught the error and addressed it, if you were high. What Visa actually did was slap a $20 "negative balance" fee on it, of course.

The embarrassingly-named VISA BUXX card is a debit card for teenagers: parents get reports, control, etc. My daughter has one.

My lectures about financial responsibility appear to have failed: yesterday she charged $23,148,855,308,184,500.00 at the drug store. That's 2,000 times more than the national debt, which is a paltry 11 trillion.

The ever-vigilant folks at VISA added a $20 "negative balance fee," and have suspended the card.

When I called, they said that there was a "system problem," and that the "help desk was working on it."

Note: Some readers have speculated that the number is the credit card number, but the OP says in the comments that it's not:

Wow, I didn't think of that before I submitted this story to Consumerist. Wouldn't that be ironic cosmic retribution? Jerky consumer puts VISA's honest programming mistake on display for the world to make snarky sarcastic comments about... but then it turns out that he's just posted the debit card number!

Happily, this is not the case. Please carry on with the caustic commentary.

In that same thread, another commenter named mlcastle points out the series of digits fails the Luhn check, a simple checksum formula invented in the 1950s, and so cannot be a valid credit card number.

Update 2: Hawkins posted a follow up on page 3 of the comments: issue was with VISA, not with CVS. Apparently lots of VISA debit card users were affected by it, at several different merchants. Each victim was charged exactly $23,148,855,308,184,500.00.

The folks at VISA have removed the 23-Grillion dollar charge, but not the $20 negative-balance fee. They promise to do so "as soon as this is all sorted out.

The secret of the $23 quadrillion VISA debit errors looks like a specific and not uncommon programming error. Take the insanely large number, if you convert 2314885530818450000 to hexadecimal, you end up with 20 20 20 20 20 20 12 50. In programming, hex20 is a space. Where a binary zero should have been, there were spaces instead. What made this instance special is that it wasn't caught in time. A Slashdot commenter identifying himself as working in the industry explains more about what very likely happened:

rickb928 writes:


The only novelty here is that the error got into production, and was not caught and corrected before it went that far.

Submitters send files to processors which are supposed to be formatted according to specifications.

Note I wrote 'supposed to be'.

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...!

Seems that's what happened here. Sounds like a hex or dec field got padded with hex 20, and boom.

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.

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.

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. Please, I know data should never IPL a system. Tell it to the architects, please. As if they don't know now, after the one crash...

If you knew what I know, you'd chuckle and share this story with some of your buddies in development and certification.

And pray a little.

At least it didn't overbill the cardholders by $.08/transaction. That would suck. This is easy by comparison. Just fix the report data. Piece of cake. Evening's worth of coding and slam it out in off-peak time. Hahahahaha!

DanKellFla wrote:The really appaling part is that they made him wait on the phone so long before acknowledging the error. It should have taken about 1 minute for somebody to realize that all the money in the world (and then some) could not have been charged by this guy.

vbhoutex wrote:

DanKellFla wrote:The really appaling part is that they made him wait on the phone so long before acknowledging the error. It should have taken about 1 minute for somebody to realize that all the money in the world (and then some) could not have been charged by this guy.

The really appalling part is that anyone even had to call them up and point out the error to them!!!