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.
> "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
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
> 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
> 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 M. Foster
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php