How much information does simple CC validation give?

[ILoveHostasaurus]

For me the main benefit of manually processing orders is the ability to manually vet each order before going ahead and processing it. Also I need to maintain a gateway for telephone and fax orders and paying for two gateways doesn't seem worth it.

See if your gateway is supported by Merchant, or if you can switch to one that is, it supports quite a few. It's unusual that you'd be paying for a gateway already though for telephone and fax orders since you'd normally just communicate directly with your merchant account either by terminal or a web interface to that merchant account, bypassing the need for a gateway.

However you mention that your gateway still gives you manual control over every order. Does this work by processing the transaction but holding it back from the bank before it gets your final approval? I would seriously consider moving to a gateway that provided this option, but in the past gateways that I looked at didn't let me do this.

Yes, in Merchant you can set the gateway to authorize only, meaning the card is checked that the charge could be put on it and the order completes but the person has not been charged. You go back later in the store and 'process' the order to charge the person. If you commonly need to change the amount that you charge the person, you'll want to use a gateway that allows you to either store the card number so you can then run it through later on their site or that has a web interface where you can adjust the charge as part of the delayed capture on their site and then run that through.

[wmgilligan]

Its like an ex-president saying he didn't do something...

Just a quick followup (I added the bold)
From: Visa U.S.A. Cardholder Information Security Program (CISP)
Frequently Asked Questions
==================
5. When is it acceptable to store Card Verification Value 2 (CVV2)?

It is never acceptable for Acquirers, merchants, or service providers to retain CVV2, which consists of the last three digits printed on the signature panel of all Visa Cards, subsequent to transaction authorization. The Visa Operating Regulations prohibit such storage, whether encrypted or unencrypted.

So the question becomes - when does authorization occur? With simple validation, this occurs sometime after the order is placed. at that point, this info MUST BE DELETED.

http://www.usa.visa.com/download/business/accepting_visa/ops_risk_management/cisp_FAQ.pdf?it=il|/business/accepting_visa/ops_risk_management/cisp_tools_faq.html|FAQ

[ILoveHostasaurus]

Authorization never occurs with simple validation, you just charge the person at a later point in time at your leisure. The CVV data is also not encrypted when stored, also against their policies. You can argue the semantics of Visa's regulations, even though I highly doubt that the spirit of that do***ent is to suggest to people that they freely store the CVV as long as they feel like as long as they don't do anything with it, but it does not preclude the fact that merchants are being defrauded as a direct result of people storing the CVV.

PS Miva, please ease up on the word censor a bit.

[d_host]

True, but when it comes to legal issues, it's often the spirit of the law that gets debated in court rooms, not the letter of the law. If it was "illegal" to collect CVV2 codes before the authorization takes place, all those mail order forms and magazines and other non-Internet forms would not be allowed to ask for the CVV2 code in the first place, right?

There are multiple "how-to docu.ments", "best practices", and other docu.ments that you can get from all credit card companies. They often contradict each other. Why? Because these are not "legal docu.ments" - just recommendations and suggested practices. I actually did talk to both Visa and Amex on this issue and I asked specifically what the legal stance is. Both companies said they allow for collecting the CVV2 code long enough to process a transaction, but you must then immediately destroy the CVV2 code so it's not retained online, stored off-line, encrypted or otherwise.

Don't get me wrong - I don't necessarily agree with the practice. My own Discover card was hijacked somehow last week and, get this, used at a Wal-Mart in Naples, FL - two places you'll never see me at - and what's even better is that it was a "swipe" type transaction - all the while I still have my card on me. Discover security guys said that whoever programmed the magnetic strip on that fake card got everything right, even the CVV2 code. And while I completely support not collecting the CVV2 code, I fault the the merchant himself, Wal-Mart, who failed miserably for processing a $1560 transaction without verifying the cardholder's ID.

Yes, ultimately merchants pay the fee for all fraud, but it's a two way street. Crooks will try to scam merchants all the time, and merchants should be on the lookout and never accept transactions, especially higher ticket items, without verifying anything. It always amazes me when merchants leave their stores in auto-capture mode (SALE type transaction) and then use email notifications to ship orders out - without EVER looking at the AVS or CVV2 response codes from their gateway... What we need is not scaring people about the dangers of collecting the CVV2 code, what we need is more, a lot more, education for merchants on how to process cards in the first place. Most small merchants and startup online stores don't have a clue what AVS or CVV2 is and how (and why) to verify it, and what to do when these codes don't match.

[ILoveHostasaurus]

True, but when it comes to legal issues, it's often the spirit of the law that gets debated in court rooms, not the letter of the law. If it was "illegal" to collect CVV2 codes before the authorization takes place, all those mail order forms and magazines and other non-Internet forms would not be allowed to ask for the CVV2 code in the first place, right?

No one said it was illegal. And ignorance is not a valid legal defense, so whoever these magazines are that are asking for the CVV could be just as incorrect in doing so.

I actually did talk to both Visa and Amex on this issue and I asked specifically what the legal stance is. Both companies said they allow for collecting the CVV2 code long enough to process a transaction, but you must then immediately destroy the CVV2 code so it's not retained online, stored off-line, encrypted or otherwise.

Okay, and you obtained an answer that has no use since they didn't define what just long enough is. Is it one year or one hour? Relating to Merchant specifically, the modules most commonly used to collect the CVV do not always purge that data later and they certainly don't store it encrypted, which is what Visa says must be done.

I fault the the merchant himself, Wal-Mart, who failed miserably for processing a $1560 transaction without verifying the cardholder's ID.

So Walmart deserved to lose $1560 of merchandise because they allowed someone to pay without showing an ID? And you know for a fact that the person didn't have an ID? If they're capable of replicating a credit card and mag strip, it would not be too difficult to create an ID. Is every merchant at fault when they get defrauded or just if the dollar amount is high enough? Is it within regulations/law to require an ID before someone can purchase? I know many do it but who knows if it's supposed to be allowed.

What we need is not scaring people about the dangers of collecting the CVV2 code, what we need is more, a lot more, education for merchants on how to process cards in the first place. Most small merchants and startup online stores don't have a clue what AVS or CVV2 is and how (and why) to verify it, and what to do when these codes don't match.

So you're saying teach merchants to verify the CVV while at the same time telling me to stop discouraging merchants from collecting it which is what leads to criminals having valid CVV numbers in the first place. Teaching them to verify it is going to do nothing if the person just stole a valid CVV from the web store 'next door' and has all the proper information to go along with it.

[Vic - WolfPaw Computers]

The bottom line is that it simply is not worth the risk.

If you want to gamble on poor advice and collect and store CVV2 numbers, understand that you risk huge fines, possible termination of your merchant account and blacklisting - preventing you from obtaining another merchant account.

Regardless of how fine tooth a comb you go through the rules & regulations, and how you choose to interpret the definitions of a couple key words...is a BAD IDEA.

If that is worth it to you to save a couple bucks a month - so be it.

It certainly is not recommended or advised by us at all. Use simple validation and do not collect or ask for CVV2 - or get a real time payment gateway if you need to utilize CVV2.

[d_host]

Okay, and you obtained an answer that has no use since they didn't define what just long enough is. Is it one year or one hour?

Good question. I believe this is spelled out somewhere in the general credit card collection rules (not CVV2, just the card number itself) and if my memory serves me correctly - the timeframe is 30 days. This is what credit card companies TYPICALLY allow for cases where a product is perhaps backordered and merchant is allowed to retain the card number on file for up to 30 days to re-run the transaction when the product is again in stock. From what I recall reading, if a product is backordered for more than 30 days, merchant is not allowed to resubmit the original transaction without prior approval from the cardholder.

So - it sounds to me like if you can keep the card number on file for 30 days, logic would say that storing the CVV2 code before processing the transaction would also mean "30 days" - but that's just my guess. Again, if you challange the law, you'll be talking spirit of the law, and if Visa/MC/Discover/Amex allow 30-day retention on card numbers for processing purposes, logically this would/should include the CVV2 code.

Keep in mind, while I'm saying this, I am NOT saying I advocate collecting and/or storing of the CVV2 codes. I firmly believe in using real-time payment gateways for this purpose, and that's what we suggest to all clients every single time this topic comes up.

Relating to Merchant specifically, the modules most commonly used to collect the CVV do not always purge that data later and they certainly don't store it encrypted, which is what Visa says must be done.

I don't know of any modules that purge the card numbers and/or CVV2 data, other than perhaps some of truXoft's modules. However, Visa doesn't say you have to store the data encrypted - they just say you can't store it, period, *after* processing the transaction.

So Walmart deserved to lose $1560 of merchandise because they allowed someone to pay without showing an ID? And you know for a fact that the person didn't have an ID? If they're capable of replicating a credit card and mag strip, it would not be too difficult to create an ID. Is every merchant at fault when they get defrauded or just if the dollar amount is high enough? Is it within regulations/law to require an ID before someone can purchase? I know many do it but who knows if it's supposed to be allowed.

Stealing a card number, along with the CVV2 code, is incredibly easy. Every time you go to a restaurant and pay your bill with a credit card, the waiter/waitress takes the card and disappears with it for 5, 10, 15 minutes. It wouldn't be difficult at all for someone unscrupulous to collect card numbers along with the CVV2 codes and names on cards all day long. Reprogramming the magstrip is also relatively easy. You see this all the time where people sell the data they collect through the course of their regular day jobs - whether an AOL staff with access to customers' email addresses (sold over a million addresses to several spammers) or a movie critic (sold movie screeners to pirate web site operators for distribution before official theatrical release dates). Creating a fake ID, while also doable, would require a lot more masterminding and time for a VERY short window of opportunity the fraudster would have since generally such cases are caught and cards terminated within a few hours to maybe a day or two. (Discover calls the cardholder within minutes of any unusual activity, which is how I learned about the Wal-Mart in FL case). Do I know whether Wal-Mart checked the ID of that person? No, I don't. But considering Wal-Mart is also the type of company where you can use a $1000 bill and get change for it, it would not surprise me at all if their checkout clerks just didn't pay attention or care to verify the ID.

So you're saying teach merchants to verify the CVV while at the same time telling me to stop discouraging merchants from collecting it

Absolutely not! What merchants need to know is what CVV2 code is, what it's for, how to deal with it, and know that the best way to deal with it is to use a real-time payment gateway - so they can verify the code without actually seeing it - and then show them what to do with the AVS and CVV2 response codes. I'm not advocating one thing against the other, on the contrary, I think people just DON'T KNOW any better and that's why we constantly see requests from new online merchants on how to collect CVV2 data in their stores when they use Simple CC Validation. If merchants knew the pitfalls of doing that, they wouldn't be asking such questions, but like I said - they just don't know it's not something that's not supposed to be done.

While this is a bit of an extreme... we have to pass written and driving tests to get a driver license, to show that we understand the rules of the road and that we can drive responsibly and won't kill everyone on the road. Why are we, then, allowed to steamroll through other people's financials, destroy credit ratings, and add to the indentity fraud cases by not making sure that those who are allowed to accept credit cards can do so responsibly? It may not have a physical impact on people like running someone over with a car, but credit card and identity theft is a huge problem and can have a terrible impact on those who fall victim to it. If I had to venture a guess, I'd have to say that probably a good 60-80% of online merchants don't know how to deal with AVS and CVV2 codes or don't even know they should be looking at the response codes from their payment gateways. That's the scary part. Telling people they shouldn't be collecting CVV2 codes while they really need/want to do so to get better discount rates and lower fees on their transactions is not telling them the full story and WHY they should explore safer methods of processing credit cards - for the customers' and their own good (since ultimately merchants pay for all credit card fraud anyway).

[ILoveHostasaurus]

Okay, now we have an answer from Visa's security team. Basically, if you accept a card, you have 24 hours to authorize it. During this 24 hour period, you are permitted to store the CVV2 but ONLY if it is stored persuant to the terms of the PCI Data Security Standard. Since there is no Miva Merchant module that collects and then encrypts the CVV2, there is no way to satisfy this requirement with Miva Merchant since encrypting the data is a requirement of storing the data. Here's the full message:

Dear David,

If the CVV2 is stored prior to authorization for batch processing (such as for telephone order transactions), then the batch should be completed daily and the stored CVV2 purged immediately following authorization.

For normal transactions (i.e., non-batch), industry standards prescribe an immediate or within a 24-hour window allowed for authorization. While it is stored, all of the PCI Data Security Standard requirements apply to safeguard this highly sensitive data. Long-term storage of the CVV2 (beyond the day's batch process) would be considered a violation of the Visa Operating Regulations.

In such cases of delayed shipments, initial authorization must be made within the 24-hours of obtaining the CVV2. Once the shipment is ready, the balance that must be authorized no longer falls within the same transaction category as "initial" (i.e.,., it is of a different type of transaction) and will not necessitate CVV2. Hence, CVV2 must be purged once initial authorization has been made.

CVV2 can be viewed as a verification tool in lieu of a physical signature for card-not-present transactions. Therefore, the cardholder can be identified using the CVV2 during the initial authorization as opposed to a verification tool for account balance available.

We suggest contacting an acquirer for the specific process necessary for initial authorization and CVV2 as well as delayed shipments, recurring transactions (which follows the same logic as delayed shipments), and other cir***stances.

Best,
CISP Team

[vincem]

Payflow Pro / Cvv use

I'm using Payflow Pro and have verisign set to capture and check address, zip and cvv. Even though they come back as a "N" the order still gets processed. Is there something else I need to do on the Miva side to reject these orders?

thanks!

Vince

[d_host]

If you want to reject orders based on AVS and/or CVV2 response codes, you need to work with Payflow Pro and sign up for their various fraud prevention packages. By default as long as the card is in good standing, wrong CVV2 and AVS response codes will not decline the card - it's only for you to see whether there was a match and decide if you want to take the risk. If you absolutely want to insist on declining transactions if these numbers don't match, the only way to do this is to use Payflow Pro fraud protection services to customize how and what you want to decline, in addition to the card being declined.

[ILoveHostasaurus]

I always forget which way this works but you may be able to call Versign and tell them to reject those, or you may have to add their basic fraud service before you're able to tell them to reject those as Merchant itself doesn't have a way to reject them. Maybe a developer with the limited source kit could write a new version of the mod that sends a void back to verisign and rejects if the CVV is N though.

[vincem]

thanks guys! I thought this may be the case but also seems like there should be a way in miva to reject since it is receiving the data from Verisign.

[ILoveHostasaurus]

There's actually a bunch of fraud things that Merchant could do but it would require the module to have quite a bit of code added to process all the different possibly responses, etc. Miva just recently converted the version 5 mod to use PayPal's new API so hopefully other changes like these features will be on the way at some point.