- Starting on page 10 is a great "Payment Card 101" that describes how a credit or debit card transaction flows through the system. The graphics are a lot slicker than the version I developed when I was at Visa (after all, it has been about 15 years!), and there is good text, too.
- Page 14 offers a description of "convenience fees." The short answer is "the merchant must [Visa's emphasis] adhere to Visa rules." Want to know what the rules are? Simple... "please contact your acquirer."
- Also on page 14 is one of my favorite topics: transaction laundering. It says that "Depositing transactions for a business that does not have a valid merchant agreement is called laundering. Laundering is not allowed." That means you don't process for unrelated third parties using your merchant ID. In fact, I wouldn't even allow a third-party merchant on my network. Either it is laundering (I call this "LaunderNet") or you are a Service Provider, and each is bad news from a risk and PCI perspective.
- Page 15 tells you not to do cash or check refunds for card transactions. You are supposed to issue a credit back to the original card used. Even if it isn't a Visa requirement, this procedure is a good idea since it prevents another form of transaction laundering: charging a transaction with someone else's card (e.g., their parent's or roommate's, with or without permission) then getting a cash refund. Bad news all around.
- Page 17 talks about your third-party service providers.
- Check out page 22 for good advice on your POS receipts.
- Page 35, and later page 80 cover the CVV2 (the security code on the back of the card).
- And of course, if you actually want to learn more than you ever wanted to know about chargebacks and copy requests, that all starts getting serious around page 41.
Thursday, May 26, 2011
Visa Chargeback Publication: More than Meets the Eye
Beware of Changes to SAQ C
SAQ C previously had five requirements:
- the payment system and an Internet connection had to be on the same device
- that device was not connected to any other system in the merchant’s environment
- the merchant kept only paper reports or receipts
- the merchant stored no electronic cardholder data
- remote vendor support was managed securely.
The payoff for meeting these requirements was that a school or campus merchant could qualify to use this simplified SAQ and avoid the much longer, more involved, and significantly more costly process of using SAQ D.
Unfortunately some of you will no longer qualify to use SAQ C. The reason is that SAQ C now includes an additional, sixth requirement:
- your company store is not connected to other store locations, and any LAN [local area network] is for a single store only.
This change means if your bookstore or food service operation or whatever supports a branch or second (or more) location(s) using their single POS system, they would need to use SAQ D.
The change to SAQ C will affect many universities that have retail or food service operations, and support multiple campus locations with a single POS system. I doubt cashiering operations will be affected very much.
We talked about this issue at the Treasury Institute's recent PCI workshop. I described the changes as part of covering what is new in PCI 2.0. It surprised me how many schools had not noticed the change in the SAQ. I admit it is a subtle change, but it is an important one for a lot of schools. It likely means they either have to license some additional POS applications so they have one for each location, or they are thrown into SAQ D.
If this situation describes your campus, I suggest you get to work on it now and not wait until the last minute. I hate to be the bearer of bad news, but better you should know than get caught up at the last moment