How much information does simple CC validation give?

[luyendao]

Hi there - first of all i'd like to thank this community for always answering so quickly and politely to all my insanely new questions.

Recently my client decided they don't want to use a payment gateway, but do all the processing at their local terminal. So in order for that to work for them, when the order is made online they would need not only a credit card number, but the customer info they filled out, product, quantity and so forth.

Is there anyway for me to test or setup, what data is sent using the simple validation, and how safe is it? I've always used payment gateways (moneris), so i balked a bit when this option was chosen.

Thanks for any help, hope the above made some sense!
Luyen

[Vic - WolfPaw Computers]

Simple Validation only collects and displays the credit card holders name, credit card number, and expriation date.

It does minimal checking to ensure the numbers entered match the card type selected, contain the right number of digits, and pass the credit card alogrithim for proper card mod checks.

Thats all. As it says, simple.

Anyone taking credit cards online should really consider a realtime gateway. This will allow you to take advantage of additional fraud prevention features.

Most merchants that opt to use Simple Validation do so because they can get a better discount rate for processing the card through their terminals. What many do not know, is this may be a violation of their merchant account agreement with their card processor. Merchant accounts must clearly be internet enabled, even if they are manually punching numbers into a terminal. The transaction was via the internet, and is card not present.

You also cannot collect CVV2 numbers with simple validation, which with most processors, results in a higher fee.

[bearsnum34]

I was wondering if there was a way to code in the CVV2 number during check out. I added it to the Simple Validation opay but it doesn't print out on the order.

Thanks so much,

[Vic - WolfPaw Computers]

You do NOT want to do this. Collecting, recording or storing of the CVV2 number in anything other than for use REAL TIME in processing through a real time gateway can open you up for stiff fines from Visa/MasterCard.

If you need to use CVV2, invest in a payment gateway.

[bearsnum34]

Okay, thanks. My new cc merchant doesn't require it unless it is a corp. credit card they are using. So I guess I will not worry about it. However, the one thing I have noticed is when a customer enters their telephone number in miva incorrectly, they are not prompted to fix it.

In other words, I had or have customers that type extra numbers by mistake or don't even put a number in it. They might enter a fake number, why I don't know. Then how would I call them for the CVV2 number?

Thanks so much,

PS. I guess I just wanted the CVV2 number incase it was required when I processed the credit card. This way I didn't have to bother my customers. Most of my customers are used to putting that info in.

[Vic - WolfPaw Computers]

I strongly suggest using a realtime gateway. Many of them do validation against the other fields as well as offer you fraud protection tools.

You should make use of all the fraud protection you can. Saving a few dollars a month from not using a gateway could cost you thousands in one bad transaction down the line.

[immy79]

For your other question, MIVA Merchant does not do any validation on the phone number field. It's a feature that's been requested quite a bit, though.

[Vic - WolfPaw Computers]

You could however, edit the page and add some javascript to validate the field's input against phone number format. But I'll be willing to bet that will be more trouble than its worth. Trying to guess what format they'll type the number in is tricky, so what to reject and what to accept...

Too many strict rules and they customer will leave.

[travelgear]

IMHO, I think simple validation is the best way to avoid credit card fraud.

Basically if something looks dodgy I will notice it and take further steps to manually check the authenticity of the credit card. I would notice issues that may get past a payment gateway.

For instance I often get orders that don't look 'right'. If someone from Nigeria, Ghana, Indonesia or Russia places an unusually large order, I don't even think about processing the order - but a payment gateway may not look beyond the credit card information.

Also I can make further checks if the area code of a phone number doesn't match the address supplied by a customer. Can a payment gateway do this?

I can also check if the address details don't match the country. For instance some fraudulent orders have an Indonesian address but put Singapore as the 'ship to' country. The idea is that most merchants trust orders from a rich country like Singapore and process the order, but when the order arrives in Singapore the people at the post office will notice the wrong address and send it on to the right address in Indonesia. Now I know that Surabaya is in Indonesia and not Singapore, but I would expect that most payment gateways are not so familiar with Southeast Asian geography.

Doing things manually generally takes longer and time is money, but I process my credit cards from within Quickbooks so this is not a big issue. IMHO it is worth taking the extra time to manually vet each transaction is worth it as you get fewer chargebacks, which can allow you to negotiate lower fees with your bank.

I would never move to a payment gateway, unless it offered me the option of manually vetting every order before the gateway processed the transaction.

[Vic - WolfPaw Computers]

I strongly disagree. Unless you are violating merchant account terms and conditions - you cannot use the CVV2 code to deter fraud.

You also wind up doing much more work for yourself by having to process orders that may wind up being declined or otherwise not accepted. That is a waste of time. Especially if you have a busy store.

A responsible merchant should be visually scanning each order before shipping anyhow. Manual intervention is the best way to prevent fraud, however that should be done in addition to the fraud tools made available by a gateway - not instead of.

You always have the option to void any sale prior to your gateway batching your orders. So you do maintain manual control over every order.

[travelgear]

I agree that the inability to use the CVV code is an issue and that it does take more time, however the manual control catches a lot of fraudulent order that don't get picked up by the gateway.

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.

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.

Perhaps I will take a second look at the gateways that are approved by my bank.

[Vic - WolfPaw Computers]

All the major gateways provide you with the ability to void orders before the daily batch settles.

[wmgilligan]

Cvv

I will not tell you if its right or wrong. But I will tell you that I have read as many docs as I can find regarding the CVV and I am left with the impression that you can collect the CVV and store it long enough to process the order. Once the order is processed, the CVV must be deleted. I will also say that there are modules for both V4 and V5 that enable you to collect this info.

This is my only comment on the subject, as I know many disagree with me, and likely they will voice their alternative points of view.


Bill

[d_host]

While we all can pretty much agree that it's a bad idea to collect the CVV2 codes, the reality is that credit card companies do give merchants explicit permission to request it and store it "long enough to process a transaction" (like you said, Bill). Which is why you often see these order forms in magazines that ask for the card number, CVV2 code, etc, which people then mail out and the fulfillment house can see and use to process CC transactions. Whether they destroy these order forms or not or destroy just the CVV2 code portion is anyone's guess, but my personal one is that they probably keep these on file for some time, since they contain the cardholder's signature - and if there's a dispute or chargeback or any issues, they have "something" to forward to their merchant bank as evidence. My guess is these companies keep the CVV2 code much longer than required to just process each transaction...

I guess it boils down to being a responsible online merchant and proactively protecting your customers' personal and sensitive information, rather than storing it online indefinitely and hoping for the best and that your site will never get hacked. Storing credit card info, CVV2 codes, and other sensitive data online, on a publically accessible server, is rarely a good idea. Most "small business" merchants have no concept of security or encryption and don't have their own IT or in-house security departments to deal with these issues. Rather than risking all that data to a potential hacker - delete all processed orders from your store regularly. *IF* your site does get hacked, at most they will gain access to a handful of card numbers, rather than hundreds of thousands if you store your order history in your store indefinitely...

[ILoveHostasaurus]

I will not tell you if its right or wrong. But I will tell you that I have read as many docs as I can find regarding the CVV and I am left with the impression that you can collect the CVV and store it long enough to process the order. Once the order is processed, the CVV must be deleted. I will also say that there are modules for both V4 and V5 that enable you to collect this info.

This is my only comment on the subject, as I know many disagree with me, and likely they will voice their alternative points of view.


Bill

The merchants who end up paying for the fraud that results from those who store the CVV and end up having that data compromised at some point are who will tell you it's wrong to store it.

Here are some do***ents from Visa on this:

1) The official security audit procedures checklist that merchants and service providers who require on-site audits follow:

http://usa.visa.com/download/busines..._Reporting.doc

You'll note on page 13, requirement 3.2.1 explicitly tests for "Examine the following from the sample selected, and obtain evidence that the contents of any track from the magnetic stripe on the back of the card (CVV data) is not stored under any cir***stance:

* Incoming transaction data
* Transaction logs
* History files
* Several database schemas"

So in this case, Visa is requiring that the auditor specifically focus on multiple areas of data storage to ensure the CVV is not stored. But they go even further with requirement 3.2.2 which states "Do not store the card-validation code [three-digit or four-digit value printed on the front or back of a payment card (e.g., CVV2 data or CVC2 data)]." and then instructs the auditor to "Examine the following from the sample selected and obtain evidence that three-digit or four-digit card-validation code printed on the signature panel (CVV2/CVC2 data) is not stored under any cir***stance:"


2) Visa's 'best practices' do***ent for security:

http://usa.visa.com/download/busines..._Practices.pdf

Again, quoting the PCI Data Security Standard that ALL Visa merchants are required to comply with, it again says the CVV cannot be stored and to test by "Examine the following files created by the application and verify that the three-digit or four-digit card-validation code printed on the signature panel (CVV2/CVC2 data) is not stored under any cir***stance:
? Incoming transaction data
? Transaction logs
? History files
? Debug logs
? Audit logs
? Database schemas and tables"

3) Or you can look at the PCI standard yourself which reiterates this point again:

http://usa.visa.com/download/busines...y_Standard.pdf

4) Same for MasterCard:

https://sdp.mastercardintl.com/pdf/pcd_manual.pdf