|CVV Via email to merchant|
Can you send the cvv via email to a merchant
I started working on someone's old ASP driven site.
The way the ordering process is set up, it takes the credit card info from the customer and sends it in an email to the site owner including the CVV. As far as I know, there is no encryption going on with the emails.
I suspect that this might not be an allowable way of doing things.
- The site uses ASP.
- No data is stored on the site when an order is placed. It is transmitted via email.
- It does not appear that there is any encryption with the email to the site owner
- The email includes the order, credit card info and CVV.
- The range of line items in the catalog is about 50
Ideally, I would like to migrate to an established online cart and payment gateway. However, I don't think the client wants to make that type of major change at this point.
Again, the main question is "Is transmitting the CVV with the credit card info in an unencrypted email acceptable"? I would think it isn't
A secondary question would be if it would be allowed if the CVV was sent in a second email without the rest of the credit card info.
I'd appreciate any thoughts.
|However, I don't think the client wants to make that type of major change at this point. |
Run away! This project has too many red flags all over it.
Spend a few minutes to explain to the client that this setup violates so many terms of service and violates PCI compliance and that he is opening him to some serious liability. if you can't make him understand the gravity of the situation within 3 minutes, RUN AWAY!
Seconded. The site owner is opening themselves up to liability for any fraud that might affect customers. Even a single instance of such fraud could easily outweigh the costs to implement a basic solution that would also not risk every customer's financial security.
The PA-DSS standard requires that the merchant encrypt sensitive communications over the Internet. If the email were encrypted, and the merchant acted to protect the payment information, and didn't retain it, the practice would be fine.
An unencrypted email doesn't meet the standard of PS-DSS. But if you've ever read your card number over the phone to someone, or handed your card over to a bartender to run a tab, you've placed your payment information into a much-riskier situation than the owner of this site. I'd simply set him up with an offsite payment processor, so he doesn't have to deal with silly offline processing of credit cards.
And watch out for so-called "PCI Consultants" who will gladly charge you thousands for an audit. They do these audits without looking at a single line of source code, but instead rely on "scans" of your website. Your customer is probably considered a "Level 4" merchant, and an annual self-assessment questionnaire is required; not the payment of thousands to a consultant.
But if you've ever read your card number over the phone to someone, or handed your card over to a bartender to run a tab, you've placed your payment information into a much-riskier situation than the owner of this site.
I was thinking about posting the same after reading the OP. It does pay to read the entire thread first.
My own view is that online card processing is something that any SME should oursource.
Bad situation as is and while the chances may be slim something will happen, if it did, it could be huge issue for your client.
Why not write a quick script that dumps the data into an encrypted db instead of emailing it. Then write an admin interface that allows your client to access the info via https? He could get the data then delete the record. Of course, this brings up it's own PCI compliance issues.