Quantcast StorefrontBacktalk » Blog Archive » Macy’s: POS “Formatting Flaw” Caused Debit Card Snafu
advertisement
advertisement

Macy’s: POS “Formatting Flaw” Caused Debit Card Snafu

Written by Evan Schuman and Fred J. Aun
February 25th, 2009
Like this story? Share it
To share this story with people in your social network, please click on the network icons below.

Macy’s is now blaming a POS system “formatting flaw” for the holiday payment horror where 8,000 in-store customers’ debit cards were charged multiple times for single transactions.

The retailer initially suspected that one of its third-party payment card processors caused the problem. But in mid-January, company officials said no outside entities were to blame. Instead, they attributed the incidents to a problem with a gateway that takes debit card transactions from the POS network and coordinates them before sending them on to payment processors.

At the time, Mike Gatio, president of Macy’s credit and customer services division, said an even more vexing failure occurred in an application that was supposed to keep an eye out for identical sales tickets that are processed multiple times. Gatio said the company needed to do a full-fledged “post-mortem” on the problems.

That end-of-the-line diagnosis apparently pointed to the previously unmentioned formatting flaw.

“As we investigated the cause of the gateway issue, we discovered a formatting flaw in the software that runs our point-of-sale register system,” said Jim Sluzewski, the Macy’s VP for corporate communications, on Tuesday (Feb. 24). “This is proprietary software that we developed in-house to run our POS system. At a certain level of transaction volume, the formatting flaw caused our system not to recognize messages coming back into Macy’s gateway from our banks that a debit transaction had been approved. Absent that approval, the transaction was not accepted and the customer was asked to re-swipe their debit card–which led to the double debits when these additional transactions also went through successfully.”

Pressed for clarification of the “formatting flaw,” Sluzewski declined to elaborate. “We just don’t have the time or ability to go into a lot more detail,” he said. “It was a situation in our system, we fixed it and we are going to leave it at that.”

The Great Debit Vs. Credit Card Debate

The lack of new details makes determining precisely what happened difficult, especially when dealing with a phrase as vague as “formatting flaw” somewhere within the POS. What role did the high holiday rush traffic play? Was the system so overloaded that response times were too slow? Or was it more of a programming error, such as assuming that when more than X number of transactions are processed during any one-hour period, presume it’s an attack and suspend authorizations? No way to tell.

But the incident did serve to remind the retail community of how much more dangerous debit cards are, compared with credit cards. When a credit card sustains bad charges, it can often be credited back quickly with little to no impact on the consumer.

If the same situation happens with a debit card, it immediately impacts the consumer’s bank account, potentially emptying it out and causing a large number of checks to bounce, which can cause major financial problems for that consumer. And yet, debit card protections are no stronger than those for credit cards, despite their infinitely greater risks.

In the Macy’s Dec. 20, 2008, debit card debacle, the glitch did not affect shoppers using debit cards to make online purchases. Also, it was limited to PIN debit transactions, ignoring signature debit transactions.

Hundreds of Macy’s stores were involved in parts of Alabama, Georgia, Kentucky, Louisiana, North Carolina, Oklahoma, South Carolina, Tennessee, Texas, Virginia, West Virginia, Illinois, Indiana, Kansas, Missouri, New York, Ohio, Pennsylvania, Michigan, Minnesota, North Dakota, Ohio, South Dakota and Wisconsin.

Why Didn’t The System Work?

Volume played a major role in the problem as transactions became backed up in the processing system. Sluzewski, in January, said signals sent by the banks to acknowledge transaction approvals were not recorded by the Macy’s system, prompting store associates at POS stations to ask customers to swipe their debit cards repeatedly.

Within a half-hour of noticing the first incident, Macy’s began shifting stores to an alternate gateway that was operating properly, and the shift of all stores was completed in less than two hours, said Macy’s officials. In mid-January, Gatio said his “immediate concern” was why the automated reversal system didn’t work, as designed, to prevent double (and several triple) charges. The system was supposed to automatically send a credit to the bank for the second debit.

Sluzewski stressed that the malfunctions “happened for only a short period when our internal alarms were tripped and we began shifting transaction volume away from the gateway in question. It affected only this one gateway because it had the highest level of volume on that day.” The spokesman also pointed out that Macy’s has “corrected the software formatting issue and the system has been working well.”


advertisement

One Comment | Read Macy’s: POS “Formatting Flaw” Caused Debit Card Snafu

  1. personal loan Says:

    Merchants needs to call their terminal provider to prevent things like this from happening. Sometimes it’s the terminal that has the problem that’s why debit cards was double billed.

Leave a Reply

Newsletter

Quickly catch-up on the latest in E-Commerce and Retail Tech with our free weekly newsletter, with urgent bulletins as news merits.
advertisement

Most Recent Comments

Kill All The Passwords

This article does mention, but does not give enough attention to, the fact that the attacks discussed are only feasible when the encrypted password file can be copied and subjected to an offline attack. The trick is to have authentication performed on a separate, much more strongly secured host - such as an Active Directory Domain Controller, or a Kerberos server, or a NIS+ server, or even using something as banal as an LDAP-over-SSL authentication dialog. In these environments, the odds of the "password file" being stolen and subjected to an offline attack go to near zero, and only online attacks may be carried out by the attacker. With sensible exponential backoff between failed password attempts, lockout after a modest number of failed attempts on a single account, and pattern detection, that minimum 7 character password is quite secure enough. Passwords aren't dead yet for security purposes, and they will be with us for a very long while to come for practical purposes. The trick is to employ them correctly. Read more...
The possibilities you describe are years away from being implemented at best, so for the moment passwords are an ugly reality. Luckily, password managers can easily manage hundreds of passwords of any length. The only thing a user needs to remember is the master password. It seems like an easier task to educate users on how to use password managers rather than implement complex security technology on a global basis. Read more...