I have a client who wants to collect the CVV number of the credit card through his online store. I've counceled him that this is a violation of his merchant agreement with Visa and Mastercard which state that the number cannot be stored. Even those these numbers are encrypted, reducing the liability, I want to cover my butt on this should something ever happen.

Does anyone here have a release form template that they use in these cases (can you share), or do you simply refuse to add the CVV collection to the shopping cart?

I definitely want to get something in writing from the client releasing me from any fines or damages should something go wrong after advising them against the storage of numbers.

The question I have is...why would it need to be stored? A CVV number can be collected, sent to the payment processor, card info is processed, response is sent back, bang, everything's done.

Assuming you're doing that, the CVV wouldn't need to be stored and I personally would refuse to do it since it's not used anywhere as proof of transaction. You can legally store an IP address and the last four digits of the card number...so that would be okay. Anything else is just asking for trouble.

The client isn't using an online payment gateway. They retrieve the encrypted order and manually process the card. The encrypted orders are stored on the server for various lengths of time until they are manually purged (which is often weeks to months). That's where the problem lies.

sorry, was posting on a different thread and pc went funny so copied what i typed before it crashed and pasted on the wrong one!! just ignore this post!

LOL, thanks for the explanation, I was wondering how that applied to my question

No worries, but back to your question...

Are you saying that you cant store CVV numbers at all??

We print orders out that have all the details on (with card number ****'d out)
but the CVV number is on there...

We keep the orders for a few months then shred them...

Originally Posted by witchblade32

The client isn't using an online payment gateway. They retrieve the encrypted order and manually process the card. The encrypted orders are stored on the server for various lengths of time until they are manually purged (which is often weeks to months). That's where the problem lies.

Yeah, that is an issue. I'd suggest to you that your deeper issue, if investigated, isn't so much the CVV number as it is the process in general. Encrypted or not, storing the CC number on a server puts your client in a position of liability. I'm not sure how you're processing the cards, but pretty well any form of online processing will require a CVV number, whereas most of the offline processing methods don't require them (if not all...I'm not overly familiar with offline payment methods, since I haven't really done much with a POS terminal in about 8.5 years).

Depending on what your client is paying, the insurance policy of sorts created by using a service such as Authorize.net or LinkPoint in the States, or BeanStream in Canada, or even *BLEEEEEEEEEECHHHHHHHHH* PrayPal in some instances, may be worth the difference between what your client is paying now and what they would be paying with one of these guys.

By the way, I've used all of those services from a programming point of view, and the APIs are all easy to work with (although LinkPoint does require a DLL registration for some reason on an NT server.)

If they won't do that, then I'd walk away. It's just not worth the risk if trouble goes down.

There should be no reason why they need CVV.

The CVV is designed to assist in fraud prevention because of live internet transactions.

If your client is entering credit cards directly into their terminal or manual merchant account facility they will not need CVV. It won't even recognize it because its not an internet based live transaction system.

The other thing is it is 100% against the rules for them to capture the PAN (primary account number of the credt card) unless they are PCI compliant. Looking at the PCI DSS and saying "yeh I'm compliant because we encrypt things" doesn't cut it. If the site touches credit card data the site needs to be PCI compliant certified.

And you as their developer should be very careful you are not also putting yourself at risk of being a little bit liable if something goes wrong. If they get hit with a $50,000 fine its very easy for any client to say "Hey, we didn't set this up, our developer did". Puts it right back on you if you know what I mean.

I hope I don't get into big trouble for mentioning these guys again, but have a look at e-Path. They are a manual payment gateway that does exactly what you need and they ae fully PCI compliant. They don't ask for the CVV either.

Just be careful, this new PCI thing has already claimed the scalps of a few big developer companies that I know of simply because they were setting up systems for their clients and ignored PCI compliance even though they had been warned.

Cheers for now

I don't think it's worth the risk of losing your merchant account taking orders like that, I'd just bite the bullet and use a payment gateway

If your client is entering credit cards directly into their terminal or manual merchant account facility they will not need CVV. It won't even recognize it because its not an internet based live transaction system.

NOT if you are in the UK (Other areas I can't vouch for...) - with certain merchant accounts you HAVE to enter the CVV or you get charged 2.5% of the transaction.

The CVV has to match banks details for the registed address of the card holder.