On Mon, May 31, 2010 at 12:36:55PM -0400, tedd wrote: > At 1:38 AM -0400 5/31/10, Paul M Foster wrote: >> On Sun, May 30, 2010 at 10:50:05AM -0400, tedd wrote: >> >> > Besides, most credit card processing agencies even require that you >>> use the customer's data (cc number, expiry date and CCS) to make the >>> sale and then immediately dispose of it afterwards, usually within 24 >>> hours under a signed agreement. Holding that information for more >>> than 24 hours can be a criminal offense regardless of what type of >>> hashing you use. >> >> Not true. It depends on the type of merchant and the situation. > > *blink* > > "Not true" and "It depends" are conflicts in logic. > > Either what I said is "true" or it isn't -- and if what I said is > "true" for some (as it is and I can prove it) then what I said is > indeed "true". > > I'm curious, why say it's not "true" and then follow with "it > depends"? It appears to me that you have your mind made-up and don't > care to listen to our experiences and recommendations. > > That's Okay, but I'm simply telling you what I KNOW to be true. You > may either accept what I have to say, or reject it, but to reply that > what I say is "Not true" is somewhat offensive and confrontational. I > hope you didn't mean it that way. :-) Okay, let me be precise, then. I have no idea whether "most credit processing agencies... require...." I haven't dealt with "most credit processing agencies", so I have no way of knowing. And in fact, I don't also know whether "holding that information for more than 24 hours can be a criminal offense...." This may be a criminal offense where you live, and it may be a criminal offense in Zambatootie as well. Since I'm not familiar with every jurisdiction, I can't vouch for where or when it is a criminal offense. I do know, however, that according to the PCI DSS FAQ, storing a credit card number is discouraged, but not disallowed. Given the proper cryptographic treatment, it is definitely allowed. This also jibes with the self-evaluation questionnaire which Level 4 merchants (like myself) must complete yearly. > > >> The PCI >> validation process allows for storage of all data except the 3-4 digit >> validation number. What I'm asked for at transaction time is the CC >> number, expiration date, digits for the billing address, and the billing >> zip code. And I can get the address and zip digits completely wrong and >> still have the transaction go through. > > Party true. > > What data are used in credit card transactions are the: name of the > card holder, credit card number, expiration date, CCV number, and zip > code. I have not dealt with any credit card processors that require > the billing address -- they just use the zip code. Additionally, it > is up to the client to determine the level of security they want. > They *can* require that *all* information be correct before accepting > a sale. When you say "client" in this context, what do you mean? The ultimate customer, the company issuing the credit card, the bank, the merchant service company? > > The downside of not requiring *all* the data to be correct is that > the rate the credit processor charges for the transaction rises. > Simply and logically put, if you don't get all the information > correct, then there is risk and that risk is passed on to the client > via an elevated charge for processing -- look it up. I have been told repeatedly by my merchant service company that my rates do not and will not rise, should my "verification information" be incorrect. I have been told repeatedly that the collection of this information is for *my* benefit, to lessen the chances of *me* being defrauded. > > The up-side of getting only the minimal data is getting a sale under > a higher risk/rate -- that's the clients choice and they usually > choose it. Again, I'm not sure the definition of client as you are using it. However, I am aware that MOTO merchants (those who take credit cards over the phone, etc. and never have a physical card), like myself, pay higher rates than those who swipe them. Part of the game. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
