A 24-Year-Old Scammed Apple 42 Times In 16 Different States 419
redletterdave (2493036) writes "Sharron Laverne Parrish Jr., 24, allegedly scammed Apple not once, but 42 times, cheating the company out of more than $300,000 — and his scam was breathtakingly simple. According to a Secret Service criminal complaint, Parrish allegedly visited Apple Stores and tried to buy products with four different debit cards, which were all closed by his respective financial institutions. When his debit card was inevitably declined by the Apple Store, he would protest and offer to call his bank — except, he wasn't really calling his bank. So he would allegedly offer the Apple Store employees a fake authorization code with a certain number of digits, which is normally provided by credit card issuers to create a record of the credit or debit override. But that's the problem with this system: as long as the number of digits is correct, the override code itself doesn't matter."
$7142.85 (Score:4, Informative)
Re:Wow ... (Score:5, Informative)
The way it's supposed to work is that the store calls the issuer and requests an override code, and then keys it in themself. The bank can then tally the auth code against the store's call at the end of the day and process the charge. I have never seen a situation where the customer calls up the bank themselves.
Exploited procedural loophole (Score:5, Informative)
1: The clerk is the one that should be calling for an approval code, and the call is made not to the cardholder's bank but rather to the bank that processes the cards for the retail store. It doesn't matter what the customer's bank says (or in this case the fake bank) since the approval/authorization code must come from the retailer's bankcard processor.
2: At my store a manager override is required to "force" a bankcard approval. So even if the clerk makes the call and gets a voice approval code a manager/owner must also provide a password to allow the approval to go through. Apparently Apple has no such security check in place and clerks tan type a manual code into the POS system to force the sale to go through.
Amazingly simple scam, but also amazingly simple to prevent if the stores involved had even rudimentary procedures in place.
Re:$7142.85 (Score:2, Informative)
You aren't far off, a couple high-end 17" MacBook Pros would easily get there pretty quick.
Re:Wow ... (Score:5, Informative)
It's not a unique security code - it's a TRACKING NUMBER. This whole part of the process is designed specifically to work around an issue where the computer records might be incorrect or the computer system is in error and an actual human has to issue an authorization code.
The actual fault in the system is that the Apple Employees let Sharron make the call and GIVE them the number. Instead THEY should've called Chase directly and gotten the code.
Re:Wow ... (Score:5, Informative)
It's not a security code, it's a reference number. The transaction isn't formally authorised by the bank until the end of the day when they receive that reference number and tally it with the corresponding phone call from the retailer. *Then* the transaction is authorised. (Assuming said phone call included verbal authorisation of the transaction.)
That the Apple Store didn't know this is how the system works means it was completely open to abuse.
Re:Arrest the Credit Card Issuers? (Score:3, Informative)
It sounds like the real scammers are the credit card issues that have a system in place to override that has ZERO security in place.
The security is supposed to be that the retailer is supposed to call the bank themselves to verify it. Which they didn't do.
Re:Wow ... (Score:0, Informative)
Because, apparently, the banks system accepted the transaction.
Re:Wow ... (Score:5, Informative)
Re:Exploited procedural loophole (Score:4, Informative)
A simple work around is to alter the phone number on the card to a number you control.
Then the retailer could call the number receive the code from your accomplice and provide a valid false code.
The retailer doesn't call the number on the card, the retailer call's the merchant service center. For example, customer has a Chase Mastercard and when Apple tries to post a transaction the card receives a decline. Apple would never call Chase, but instead calls their provider (which at my store is First Data Merchant Services). Apple's provider in turn electronically contacts Chase and then provides an approval code back to the clerk. The customer (or scammer) never has an opportunity to change the phone number unless they physically get behind the checkout counter and overwrite the numbers that are posted for the retail clerks to use. So it doesn't matter what phone number is on the card, that number is for the customer's use and not for the merchant's use.
Re: Wow ... (Score:5, Informative)
No, no one ever contacted the bank. Apple's Point of Sale software was configured to accept any number based on length() of the number string. They held the number until the end of the day or some other convenient time, when they'd process it with the banks. That was stupid, and the scam is common. Retailers are starting to learn to call and verify immediately (before clearing tge transaction), not to wait until the end of the day.
Re:Wow ... (Score:5, Informative)
The info on the ID is the security measures Visa/MC have in place. They allow a merchant to enter info like address or phone number, and their computers will tell the merchant whether or not it matches the address/phone they have on file for that card. When you pay for gas with a credit card and the pump asks you to punch in your zip code, it's not collecting marketing information. It's using the zip code as a (rather flimsy) security measure to protect against someone buying gas with a lost/stolen credit card. Yeah you can ask the customer to recite their address, but any burglar who stole the card from a house or mugger who got their victim's entire wallet would know the address. A photo ID with that info, while fairly easy to fake, requires a bit more effort on the part of the thief.
Credit card security is in the dismal state it's currently in because Visa/MC/Amex have successfully transferred all the damage from fraudulent transactions onto the merchants. Since they lose practically no money to fraud, they have very little incentive to improve security. (The exorbitant interest rates are to cover the cost of credit card holders who default on their debt.) For market forces to work correctly, financial penalties for risks which fail must be linked to financial profits when those same risks succeed. What Visa et al have done is decouple the penalties from the profits (profits go to them, penalties to the merchant), leading to a situation where they are not penalized when the risks they take (poor security) fail. Consequently there is no motivation for them to improve credit card security beyond the laughable state it's currently in.
Re:Wow ... (Score:3, Informative)
The store doesn't call the card issuer for approval. The store calls their merchant bank that provided them with card processing facilities. The merchant bank then calls the card issuer to seek approval for the transaction. The merchant bank do not source the phone number of the issuing bank from the card, they use a lookup table provided my Visa or Mastercard.
Re:Wow ... (Score:5, Informative)
Re:Wow ... (Score:5, Informative)
Now, when the payment device asked for an Override code, it was the job of the EMPLOYEE to got to the back and call up the bank. We're provided special numbers to call and special codes we have to type in. It's a horribly clunky and long process which everyone hated to do, but that was it. So, this is completely the employee's fault - albeit it's really a training issue and the blame rests with Apple. I can totally see why an employee would
#1) Not want to go through that process when they need to get to the next sale
#2) Possibly be new and not completely understand the process
#3) Be susceptible to some clever social engineering - ie: There are some cases where the customer must call the bank. I need an override code from the bank to process this. The customer is calling the bank, so that means I don't have to!
So it's a big f-up, but I can totally understand how and why it happened.
Re:Wow ... (Score:5, Informative)
Ok, they way it is supposed to work
So the system is relatively secure, but the MERCHANT should have called the bank, not the customer, that is where it broke down. This system also allows for floor limits, where the merchant is willing to accept a certain level of risk and the POS device approves transactions for an amount less than a set limit. At the end of the day the POS device submits these transactions to the bank and if the cardholder does not have sufficient funds, the merchant loses out.
All these protocols have been in place for many years and dates from a time where communication between the POS and the bank was relatively expensive and slow. Dialling up for every transactions was not an option, so you would try to batch them together to achieve a lower cost per transaction.
This is a very high level explanation of the issues involved here, but should convey the general ideas.
Yes, the Apple Store managers and employees were idiots in this case