• anonymous (unregistered)

    Also, I'm a little bit curious how he figured out which card had the most transactions in a month, when the 4-digit code used to tell which card made a transaction is the same for both cards. It sounds like all the transactions would just end up in one card or the other.

    And before you say "but there was all the data from past months, and if someone used their card for a vendor his hack would assign future business to that same card", let me remind you that the data from past months is all garbage for the two cards with duplicate IDs. Nobody had noticed the issue until some VP used his card and checked his transaction record to make sure that it showed up, and realised that there were a bunch of transactions he didn't make.

  • anonymous (unregistered) in reply to Taemyr
    Taemyr:
    anonymous at 2014-06-03 10:04:
    Meanwhile, tell your boss that the bank is sending you incorrect transaction information (which is true)

    This is not true. The bank is sending incomplete transaction information. Incomplete is distinct from incorrect transaction information. - Further the bank's information is presumably in accordance with the specification.

    The structure of the data is incorrect because it allows a many-to-many relation between the cards and their transactions, when it should be a one-to-many relation. Each card can make many transactions but if a transaction can map to multiple cards, the data structure is incorrect and it's a data integrity issue.

    Sending you the wrong data is just as wrong as sending you wrong data. Possibly worse, because the flat file parsed correctly, but since there wasn't any check of the data integrity the duplicate IDs didn't trigger any red flags until someone noticed that transactions are being associated with the wrong cards.

  • anonymous (unregistered) in reply to Taemyr
    Taemyr:
    The bank is sending incomplete transaction information. Incomplete is distinct from incorrect transaction information. - Further the bank's information is presumably in accordance with the specification.
    The specification was "system will not allow cards with the same last 4 digits", so THAT is the problem that the bank should be forced to fix. Whether they want to redesign their system to remove this specification (difficult) or revoke cards with the same last 4 digits for customers who have more than one card, and re-issue new ones that don't have the same last 4 digits (easy) is really their business.
  • F (unregistered) in reply to beginner_
    beginner_:
    The real WTF is obviously Adam. If you can't explain this to your boss why it doesn't work your either dumb or should quit.

    "Explain to boss" != "get boss to understand".

    See Dilbert.

  • phuzz (unregistered) in reply to Matt Westwood

    Up until a few years ago (about 2010) the company I used to work at had a credit card processing system from Comidea. Every morning, part of my job was to login to the payment software, and print out a list of yesterday's transactions, which would include the full CC number, and date, and the amount, which the accounts team would use for, um, something accounts-y. On top of the full numbers in print outs, it would process payments by sending the CC numbers over a dedicated ISDN line via FTP (not SFPT, just plain old FTP). I always assumed that the credit card numbers were probably stored unencrypted on the disk somewhere.

  • (cs)

    Gah, I hate working on "legacy" systems like this. They aren't considered important enough to assign the proper resources, and yet the bugs are often too complicated to be solved by a simple hack or one-off solution.

  • RowanYote (unregistered)

    I would have thought the best attack on the problem was from the other direction. Have the bank issue new cards for the handful of duplicates.

  • (cs) in reply to jarfil
    jarfil:
    "Fix the bug!", they told me. So I grabbed a gun, and went to see the bank manager.
    I can lend you a GAU-8 if you need one.
  • (cs) in reply to slavdude
    slavdude:
    Gah, I hate working on "legacy" systems like this. They aren't considered important enough to assign the proper resources, and yet the bugs are often too complicated to be solved by a simple hack or one-off solution.
    Scratch "often". The correct word is "usually" or maybe it might be better to say "...bugs are almost always too complicated...".

    The reason is that all the bugs that have simple fixes got fixed years ago, and the weird shit is all that's left. Because the time between significant problems is relatively long, They Who Decide long ago decided that the support crew can be small, poor sods.

  • (cs) in reply to Mariachi
    Mariachi:
    Why not have the bank issue replacement cards for the duplicates? If they send more dupes, report them stolen or something and get more replacements. Rinse and repeat until there are no collisions.

    "No, Adam, that won't work, because it'll cause the users to do MORE data entry to set up their new cards. Just FIX THE BUG"

  • Jay (unregistered)

    I don't know whether to smack him upside the head or buy him lunch!

  • (cs)
    There were a pile of tickets...
    Remy can has English?
  • (cs) in reply to ¯\(°_o)/¯ I DUNNO LOL
    ¯\(°_o)/¯ I DUNNO LOL:
    Nope. What they did was every time they got a new Ethernet card, they checked its MAC address. If it contained an 0xFF, they threw it in the trash. I left before Ethernet ports started becoming standard on PC motherboards.
    Worked for a guy who ordered a 10 pack of Ethernet cards (10-Base-2) which all had the same MAC address. Not sure if the error was on the manufacturer or the person ordering ordered a special pack.

    In any case, he kept them. He told me "why not? They are perfectly good cards. Just don't give more than one to the same client."

  • Blah (unregistered)

    OK, the html comments were painful, but cheers on JeanLucPCard!

  • (cs)

    I am very much doubting this story.

  • (cs)

    People that create a relational data schema without a unique identifier should be sent to Gitmo.

  • Jake (unregistered) in reply to chubertdev
    chubertdev:
    People that create a relational data schema without a unique identifier should be sent to Gitmo.
    I agree, but it's not a problem here. Our developers have never heard of relational data structures.
  • Paul Neumann (unregistered) in reply to chubertdev
    chubertdev:
    People that create a relational data schema without a unique identifier should be sent to Gitmo.
    So we can release 5 of them for every 1 who capitalizes local variable names?
  • (cs) in reply to Paul Neumann
    Paul Neumann:
    chubertdev:
    People that create a relational data schema without a unique identifier should be sent to Gitmo.
    So we can release 5 of them for every 1 who capitalizes local variable names?

    Or 1 that uses redundant parentheses.

  • Wrexham (unregistered) in reply to anonymous
    anonymous:
    Sending you the wrong data is just as wrong as sending you wrong data.
    Pardon?
  • TV (unregistered) in reply to ¯\(°_o)/¯ I DUNNO LOL

    So... the REAL wtf today seems to by w(hy)tf didn't you submit that story :) Its funnier than everything recent.

    ¯\(°_o)/¯ I DUNNO LOL:
    I once worked at a place that had a custom message format for an embedded system. It used 0xFF to mark the start of fields in IPC messages, so 0xFF was not allowed in field data, because then you couldn't find the next field. (The protocol normally passed numbers as BCD.)

    They also had a PoS system, with multiple DOS-based terminals (this was back in the '90s) connected via Ethernet. There was a message defined to announce the Ethernet address of the PoS system computers, and the last field in the message was the MAC address.

    Except MAC addresses are binary, and may contain an 0xFF. But this was always the last field, always a specific message type, always a specific field ID, and only passed between the PCs, not the embedded system. They could have made it a special case.

    Nope. What they did was every time they got a new Ethernet card, they checked its MAC address. If it contained an 0xFF, they threw it in the trash. I left before Ethernet ports started becoming standard on PC motherboards.

  • (cs) in reply to cellocgw
    cellocgw:
    Mariachi:
    Why not have the bank issue replacement cards for the duplicates? If they send more dupes, report them stolen or something and get more replacements. Rinse and repeat until there are no collisions.

    "No, Adam, that won't work, because it'll cause the users to do MORE data entry to set up their new cards. Just FIX THE BUG"

    OK, then do it the other way. Accuse some poor sod of hacking the system and revoke their card and their right to a card at the same time. Bonus if you can then get them arrested (and that reduces the amount that they need to do data entry).

  • (cs) in reply to dkf
    dkf:
    cellocgw:
    Mariachi:
    Why not have the bank issue replacement cards for the duplicates? If they send more dupes, report them stolen or something and get more replacements. Rinse and repeat until there are no collisions.

    "No, Adam, that won't work, because it'll cause the users to do MORE data entry to set up their new cards. Just FIX THE BUG"

    OK, then do it the other way. Accuse some poor sod of hacking the system and revoke their card and their right to a card at the same time. Bonus if you can then get them arrested (and that reduces the amount that they need to do data entry).

    Creates a lot of data entry for HR, though.

  • Spencer (unregistered) in reply to chubertdev

    This is almost a BoFH story. It just needs the BoFH and the PFY to write a script that uses the card numbers most used for purchases to make purchases for themselves, and modify the importer to disguise the transaction as something more mundane. Or use the whole system to get the Boss (or the guy that nicked their parking spot, or the luser on the 4th floor that keeps getting viruses on his machine or making idiotic requests) either fired, arrested, or on terrorism watchlists

  • Darth Darth (unregistered)

    That image of Picard is great. I need to send it to the next 419 scammer who asks for my bank details...

  • Cheong (unregistered) in reply to ¯\(°_o)/¯ I DUNNO LOL
    ¯\(°_o)/¯ I DUNNO LOL:
    I once worked at a place that had a custom message format for an embedded system. It used 0xFF to mark the start of fields in IPC messages, so 0xFF was not allowed in field data, because then you couldn't find the next field. (The protocol normally passed numbers as BCD.)

    They also had a PoS system, with multiple DOS-based terminals (this was back in the '90s) connected via Ethernet. There was a message defined to announce the Ethernet address of the PoS system computers, and the last field in the message was the MAC address.

    Except MAC addresses are binary, and may contain an 0xFF. But this was always the last field, always a specific message type, always a specific field ID, and only passed between the PCs, not the embedded system. They could have made it a special case.

    Nope. What they did was every time they got a new Ethernet card, they checked its MAC address. If it contained an 0xFF, they threw it in the trash. I left before Ethernet ports started becoming standard on PC motherboards.

    How wasteful.

    I used to work in computer shop like 10 years ago. And I did remember some brands DO have label of MAC address printed on the box of LAN cards. They should have asked the shopkeepers to check for them.

  • Maple Leaf WTF (unregistered) in reply to anonymous
    anonymous:
    Also, I'm a little bit curious how he figured out which card had the most transactions in a month, when the 4-digit code used to tell which card made a transaction is the same for both cards. It sounds like all the transactions would just end up in one card or the other.

    And before you say "but there was all the data from past months, and if someone used their card for a vendor his hack would assign future business to that same card", let me remind you that the data from past months is all garbage for the two cards with duplicate IDs. Nobody had noticed the issue until some VP used his card and checked his transaction record to make sure that it showed up, and realised that there were a bunch of transactions he didn't make.

    Yeah, the system could work alright for a month or two, but after a few months - say a card got lost or expired - the transactions would always flow to the older card. So he'd need to check that the duplicate card that he's going to assign the transaction to is still valid.

    Speaking of CC numbers in the clear ...

    One of the PCI regulations is that you can only use the CVV / CCV / C2V (the extra three digits) to validate the transaction and then it must be discarded. You can't use it again.

    I booked through some hotel broker website - it might have been hotels.com - and found a little hotel in an out of the way small town near Tulle. When I arrived there I noticed that my booking was a faxed sheet of paper with my CCV printed on the page along with all my credit card details. They really didn't need all of that.

  • Data (unregistered)

    Why no puns about me? Me and my meta are what the article is all about.

  • Norman Diamond (unregistered) in reply to Maple Leaf WTF
    Maple Leaf WTF:
    One of the PCI regulations is that you can only use the CVV / CCV / C2V (the extra three digits) to validate the transaction and then it must be discarded. You can't use it again.

    I booked through some hotel broker website - it might have been hotels.com - and found a little hotel in an out of the way small town near Tulle. When I arrived there I noticed that my booking was a faxed sheet of paper with my CCV printed on the page along with all my credit card details. They really didn't need all of that.

    Surely there are easier ways to transfer the CVVs to the spammers who advertise them on this site.

  • Norman Diamond (unregistered) in reply to chubertdev
    chubertdev:
    People that create a relational data schema without a unique identifier should be sent to Gitmo.
    75% of the people in Gitmo were innocent.
  • Norman Diamond (unregistered) in reply to Zylon
    Zylon:
    There were a pile of tickets...
    Remy can has English?
    He does. American would be "There was a pile of tickets" but English is "There were a pile of tickets".
  • Norman Diamond (unregistered) in reply to faoileag
    faoileag:
    Those days online payments did not involve the suffix number and I was very tempted to see if .....4right_checknumber had been issued as well.
    It probably had been. You would only have to guess the expiration date and the cardholder's name.
  • (cs) in reply to Darth Darth
    Darth Darth:
    That image of Picard is great. I need to send it to the next 419 scammer who asks for my bank details...
    Send them this one instead: [image]
  • MrOli (unregistered)

    There's a really, really easy way to fix this: Cancel one of the duplicate cards. The new one will arrive with a different number.

  • iMalc (unregistered)

    Bzzzt, wrong solution!

    Right solution: You push back. You escalate. You explain that there is not a programmer in the world that can solve the problem because the problem is on the bank's end. You attend high level teleconference meetings where often little or progress is made, and it's more of a finger-pointing exercise. You ask the right provocative questions in front of many other people from both parties at such meetings. E.g. "What would they have our system do, guess which card each transaction is for, knowing full well that it will often be wrong?". Or "Does xyz bank not have more than 10000 customers... perhaps we should do business with a larger bank?". Sooner or later, they will get the idea and they WILL fix it.

  • (cs) in reply to MP
    MP:
    ratchet freak:
    birthday paradox says you only need 118 to have a more than 50% chance to get a dupe

    If my math is correct, you should be able to do it with only 101:

    ((101 * 100) / 2) / 10000 = 0.505

    Incidentally, with 118, I got this;

    ((118 * 117) / 2) / 10000 ~= 0.69

    Now wondering whether this was a very clever and subtle 69 joke...

    If your math were correct, as soon as you had 142 cards, you'd have a greater than 100% chance of duplicates.

  • quis (unregistered) in reply to da Doctah
    da Doctah:
    In the long run, his simple heuristic would almost certainly fail to categorize transactinos correctly, but Adam wasn’t concerned with the “long run”.
    Transactinos.

    I like it.

    An uncharged, massless particle, almost impossible to detect.

    I'd have thought that transactinos would have been atomic...

  • mark tosley (unregistered) in reply to balazs
    balazs:
    ¯\(°_o)/¯ I DUNNO LOL:
    I once worked at a place that had a custom message format for an embedded system. It used 0xFF to mark the start of fields in IPC messages, so 0xFF was not allowed in field data, because then you couldn't find the next field. (The protocol normally passed numbers as BCD.)

    Once I saw an application that were sending out large messages via MQ. It had been decided that those messages must be cut into multiple parts of 32000 characters. They also invented a brilliant solution to mark the last message with appending the character sequence "END" to it. It all worked "fine" until one of the records in one of these messages contained a partner company's name of "VENDING MACHINES Co." or "HAPPY-END Co." or something like that and also that message got cut right after the "END" sequence like "VEND" + "ING MACHINES". The rest of the story is up to your imagination. (Got fixed, nothing interesting)

    I facepalm every time I encounter some fucked-up data format that has arbitrary-length fields but no bloody escaping. Every one of those is a WTF waiting to happen. What is so goddamn hard to understand about the concept of escaping?
  • anonymous (unregistered) in reply to Wrexham
    Wrexham:
    anonymous:
    Sending you the wrong data is just as wrong as sending you wrong data.
    Pardon?
    If I ask you for data with a unique primary key and you give me data with the last 4 digits of the card number as a non-unique key, then you're giving me correct data yet the wrong data. The information stored in that column is what it claims to be on the surface (the last 4 digits of the card) yet it is not what it needs to be for data integrity (a unique key).
  • Masaaki (unregistered) in reply to Mariachi
    Mariachi:
    Why not have the bank issue replacement cards for the duplicates? If they send more dupes, report them stolen or something and get more replacements. Rinse and repeat until there are no collisions.

    Which only works if less than 9999 people are issued cards.

  • anonymous (unregistered) in reply to Masaaki
    Masaaki:
    Mariachi:
    Why not have the bank issue replacement cards for the duplicates? If they send more dupes, report them stolen or something and get more replacements. Rinse and repeat until there are no collisions.

    Which only works if less than 9999 people are issued cards.

    No. It's like a MAC address. Duplicates are not a problem as long as the cards won't be used on the same network. If the last 4 digits are used on a customer's unified billing statement to identify which of multiple cards were used to make a transaction, then it follows that you can't give a single customer more than one card with the same last 4 digits, or they won't be able to tell them apart on their unified billing statement.

  • (cs) in reply to iMalc
    iMalc:
    Bzzzt, wrong solution!

    Right solution: You push back. You escalate. You explain that there is not a programmer in the world that can solve the problem because the problem is on the bank's end. You attend high level teleconference meetings where often little or progress is made, and it's more of a finger-pointing exercise. You ask the right provocative questions in front of many other people from both parties at such meetings. E.g. "What would they have our system do, guess which card each transaction is for, knowing full well that it will often be wrong?". Or "Does xyz bank not have more than 10000 customers... perhaps we should do business with a larger bank?". Sooner or later, they will get the idea and they WILL fix it.

    Wow, you're optimistic.

  • anonymous (unregistered) in reply to Masaaki
    Masaaki:
    Mariachi:
    Why not have the bank issue replacement cards for the duplicates? If they send more dupes, report them stolen or something and get more replacements. Rinse and repeat until there are no collisions.

    Which only works if less than 9999 people are issued cards.

    "10000 or fewer"

    not

    "less than 9999"

  • Bernie The Bernie (unregistered)
    until the support for the app moved offshore
    Poor Nagesh!
  • dude (unregistered)

    The bank staff probably knew about the issue, but fixing it would alert everyone all at once and they probably don't want to come under that level of scrutiny.

    If you don't get the support from your employer then it's likely that getting it fixed properly will be career limiting in the long run. You're fooling yourself if you think you have any career prospects with someone as clueless though.

  • Jay (unregistered) in reply to Dan
    Dan:
    "If one and only one card had previous transactions with this vendor, assign the transaction to that card."

    How do you do this if you dont know what card did what?

    Umm, yeah. The whole "solution" seems to fall down on this point.

    Day 1: We have only one card with suffix, say, 4242. We get a transaction from vendor A for 4242. Cool, we assign it to that card.

    Day 2: We get a second card with suffix 4242.

    Day 3: We get a transaction from vendor A for 4242. I guess it goes to the first card 4242.

    So the second card 4242 will NEVER get any transactions from vendor A.

    It's not a matter of "whoever had the most". It's a matter of "The first card with that suffix gets all transactions. Subsequent cards with the same suffix never get any transactions." (Or transactinos, as the case may be.)

  • Jay (unregistered)

    When the bank says that no two cards have the same last four digits, but you have a data file showing multiple cards with the same last four, can't you just say to the bank, "Okay, please look up the card numbers for Bob Smith and Mary Jones. What are the last four digits of each?"

    I would think the solution to this problem is to explain the situation to someone suitably high up in the organization and get them to contact the bank and demand that they fix the problem.

  • SomeName (unregistered)

    What's with that explanation to his boss? "Bank doesn't send us correct information so I cannot do anything" should have been the answer. After that it's boss' problem to sort it out with the bank (aka change banks).

Leave a comment on “Half Credit”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article