Billing Address (at least the street number) is used in conjunction with the zip code for AVS checks. On 5/31/10, tedd <tedd.sperling@xxxxxxxxx> 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. :-) > > >>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. > > 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. > > 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. > >>We've been doing it this way for 14 years and using the type of service >>you suggest would be expensive and impractical. Only in the last two >>years has PCI become more stringent in their requirements. And >>consequently, I'm having to re-evaluate how we store this particular >>information. Otherwise, our physical and other security is more than >>adequate. Yes, of course, if you have a machine gun or you're Kevin >>Mitnick, or you have a network of 20,000 bots pounding on my router, >>you're coming in anyway. Again, this is about *reasonable* security. > > You asked for opinions -- do what you want. :-) > > Cheers, > > tedd > > -- > ------- > http://sperling.com http://ancientstones.com http://earthstones.com > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Sent from my mobile device -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
