[cautious]

Good info. Thanks.

My bad - that I always forget that there is always an exception for the big fish, for the "privilegeds".

But we have taken the advise of our IT to not emulate the big boys; therefore, we've taken the "best course of action is avoidance" approach. We never store the cvv (encrypted or not). The consequences/implications of this approach are these --- and they should be familiar with businesses that follow the same "avoidance" approach:

1. We do not take credit card #s over the phone anymore. So there is no danger that the numbers will be written down somewhere and not shredded after authorizing the charge via a virtual terminal. The customer in physical possession of her card is always in charge of authorizing the payment via the secure ssl channel we provide.

2. We do not have an exchange. Technically, we do; but not in the traditional sense. All of our exchanges are processed as Returns, meaning that we will process an exchange by first refunding any due amount. Then the customer, if he so wishes can purchase the replacement item himself with his card. Why?
Usually, our typical exchange is the customer wanting to get a replacement item that costs more than the original. The vitual terminal interface at our payment processor requires both the main# and the cvv to authorize payment. Since we did not store the cvv then we are stuck and unable to charge the customer the extra difference due to the replacement. But our gateway does not need cvv for the merchant to refund a card. Hence, we process the exchange by refunding the amount due. The customer who is in physical possession of both the card can then buy the replacement item and authorize it herself.

Again, good info. And thanks for sharing the expertise.