Hi,
I'd just like to point out that storing of CVV2 codes from credit cards is actually not allowed as set out by the credit card companies (Visa and Mastercard).
I see that nopCommerce actually does save this information and displays it in the order information. You should take this out in the next release.
Nathan
CVV2 data
- 9
- 125
- 7/2/2009
- United States
Thanks for the response. It is good to know that it is not stored for the other methods. I also understand that many merchants cannot run the card at their business without the CVV code. That is why payment gateways exist.
However, if you read the cardmember agreements, they explicitly say that you cannot store CVV data, even when it is encrypted. Just my two cents, but I think nopCommerce should have an option to store the CVV data, but have it disabled by default. If someone chooses to enable it, display a message that they may be violating the terms of their cardmember agreements and are putting themselves at risk of huge fines and indefinate termination of their merchant accounts.
"*Merchants or their agents that store, process, or transmit data may not store sensitive authentication data (full magnetic-stripe or chip) contents. Card Verification Value 2 (CVV2), or PIN Verification Value (PVV)—even if it is encrypted. Once an authorization is processed, such data should no longer exist. The only components of the magnetic stripe that can be stored are name, account number, and expiration date."
Source: http://usa.visa.com/download/merchants/rules_for_visa_merchants.pdf
My suggestion is to type CVV into the search bar and read all the sections on CVV.
However, if you read the cardmember agreements, they explicitly say that you cannot store CVV data, even when it is encrypted. Just my two cents, but I think nopCommerce should have an option to store the CVV data, but have it disabled by default. If someone chooses to enable it, display a message that they may be violating the terms of their cardmember agreements and are putting themselves at risk of huge fines and indefinate termination of their merchant accounts.
"*Merchants or their agents that store, process, or transmit data may not store sensitive authentication data (full magnetic-stripe or chip) contents. Card Verification Value 2 (CVV2), or PIN Verification Value (PVV)—even if it is encrypted. Once an authorization is processed, such data should no longer exist. The only components of the magnetic stripe that can be stored are name, account number, and expiration date."
Source: http://usa.visa.com/download/merchants/rules_for_visa_merchants.pdf
My suggestion is to type CVV into the search bar and read all the sections on CVV.
- 1
- 5
- 7/9/2009
- United States
Been doing eCommerce a long time but just started checking out nopCommerce. This is a fantastic project. Keep up the good work. This is better than most of the osC-based PHP carts I've seen in my days.
Have to agree w/ sweeperq on this one. As mentioned, there are store owners that don't use gateways and need the CVV to run the card [filjan]. The agreement merchants sign to process cards expressly forbids storing this data in any form. So our options at this point are:
1) Disobey the Agreement: Risk huge fines, risk your business, risk your customer's data [Look @ what happened to T.J. Maxx]
2) Call Customers for CVV: Reduce CC fraud risk to almost 0, doesn't violate agreements, slight inconvenience to you and customer [Not really an option since nopCommerce always stores CVV]
3) Use a Payment Gateway: Don't need to store any CC data, performs fraud checks like AVS (address matches card), don't have to manually process cards, costs a little more
If a merchant can't afford to use a payment gateway, then they most likely have a small order volume and can call customers for their CVV. Then again, if order volume is small and inventory value is low, the merchant isn't risking much by storing the CVV. That is, unless they have an offline store that does well or are operating as a sole-proprietorship; then say goodbye to the brick & mortar store or the house if you ever have a breach or get audited.
Merchants that ignore their contracts are typically those with the least amount of security around their systems and are the reason that everyone pays higher rates. In a perfect world, if none of us stored CC#'s (only transaction ids and auth codes) most risk would fall back to the Gateways and the Banks.
Anyway... Being that this project is open source, we can modify our own version to meet our needs. But I do agree with the recommendation to at least make storing of the CVV optional.
Another option might be:
* First and last numbers are sent in an email with the order number
* Middle numbers are stored encrypted in the DB
* Run the card
* Delete the email
Technically, you never store the actual CVV number and should be in compliance with your agreement. The hacker would need to have access to both your email and the admin section of your web app (since it is encrypted in DB) to rebuild the CVV. The only downside is that email is not 100% reliable, especially on shared hosts, so you will probably have to call a customer every now and again for their CVV.
Just my two cents,
Sam
Have to agree w/ sweeperq on this one. As mentioned, there are store owners that don't use gateways and need the CVV to run the card [filjan]. The agreement merchants sign to process cards expressly forbids storing this data in any form. So our options at this point are:
1) Disobey the Agreement: Risk huge fines, risk your business, risk your customer's data [Look @ what happened to T.J. Maxx]
2) Call Customers for CVV: Reduce CC fraud risk to almost 0, doesn't violate agreements, slight inconvenience to you and customer [Not really an option since nopCommerce always stores CVV]
3) Use a Payment Gateway: Don't need to store any CC data, performs fraud checks like AVS (address matches card), don't have to manually process cards, costs a little more
If a merchant can't afford to use a payment gateway, then they most likely have a small order volume and can call customers for their CVV. Then again, if order volume is small and inventory value is low, the merchant isn't risking much by storing the CVV. That is, unless they have an offline store that does well or are operating as a sole-proprietorship; then say goodbye to the brick & mortar store or the house if you ever have a breach or get audited.
Merchants that ignore their contracts are typically those with the least amount of security around their systems and are the reason that everyone pays higher rates. In a perfect world, if none of us stored CC#'s (only transaction ids and auth codes) most risk would fall back to the Gateways and the Banks.
Anyway... Being that this project is open source, we can modify our own version to meet our needs. But I do agree with the recommendation to at least make storing of the CVV optional.
Another option might be:
* First and last numbers are sent in an email with the order number
* Middle numbers are stored encrypted in the DB
* Run the card
* Delete the email
Technically, you never store the actual CVV number and should be in compliance with your agreement. The hacker would need to have access to both your email and the admin section of your web app (since it is encrypted in DB) to rebuild the CVV. The only downside is that email is not 100% reliable, especially on shared hosts, so you will probably have to call a customer every now and again for their CVV.
Just my two cents,
Sam