The Future of Consumerist

Over the last twelve years, Consumerist has been a steadfast proponent and voice on behalf of consumers, from exposing shady practices by secretive cable companies to pushing for action against dodgy payday lenders. Now, we’re joining forces with Consumer Reports, our parent organization, to cultivate the next generation of consumer advocacy.

Stay tuned as Consumerist’s current and future content finds its home as a part of the Consumer Reports brand. In the meantime, you can access existing Consumerist content below, and we encourage you to visit Consumer Reports to read the latest consumer news.

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:

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!