Thread: CC Card Numbers being deleted when StoreCCInDB is true

We have a client who is doing manual processing and needs to store both the CC# and CVV code in the DB (despite our advice against doing this).

Despite changing the StoreCCInDB app config to "true" we are still seeing the DB being purged of CC#'s after some time. I say after some time because I have so far been unable to pinpoint the circumstances or exact length of time that it takes for this to occur. The client is a bit slow to give feedback so I get a chance to work on the project every few days. It seems every time I come back to the project the test orders that I had placed last time have had their CC#'s set to NULL.

What are the circumstances which would cause a CC# to be purged even with StoreCCInDB turned on? I have not been able to find where this is happening in the source (C#).

Any help would be greatly appreciated!

StoreCCInDB will only affect credit card numbers that are stored after that value has been set. Also the customer can still choose not to store credit card information.

Also just as a bit of information, from what I have been told we do not ever under any circumstances store the CVV codes, as this is not allowed.

You would need to find where the user is given the option and turn it off.

Thanks for the quick response John!

The 5 most recent test orders have in fact been placed after StoreCCInDB was turned on. Of those 5 there are 4 that are now missing the CC# the latest one having been placed 5 days ago. The most recent order that I placed today still has the CC#. This is after marking the orders as captured.

As for not storing the CVV code - we've tried many times to tell our client that is is a bad practice - one that is out in legal grey area. We've told them the risks and liability but they insist that this is how they do business. I have already modified the checkout process to encrypt it and store it in the DB.

I also removed the option for customers to turn off storing their CC - again I agree it's a baaaad practice but this particular client is being stubborn about it :-(

I still really need some help on this please - I cannot find why this is happening.

The only things in the stock software that clear out CC records are the aspdnsf_PABPEraseCCInfo stored procedure (which runs at app start and removes info if your store's not set to save it) or running monthly maintenance with the right option selected. Beyond that, you may want to review the modifications that were made to ensure there isn't anything causing the issue there.

Hi Peps,

I'm in the same boat as Steve. Have not recommended my client to store anything unless performing re-occurring billing. However they insist for the short term they want to manually process card payments and have the CC# & CVV stored.

The clients ASDNSF store has some weird behavior. For some reason when customers are typing in the Credit Card Verficiation Code the database stores the last four digits of the CC#. Any idea's why this happens and why it does not store the CVV. Otherwise why not take that text input field out all together if it does something else?? Seems very strange to me!

Steve I'm interested to find out how you managed to encrypt and store the CVV codes?? Any hints or tips would be greatly appreciated.

Kind regards,

To my knowledge, it is not legal to store the CVV code. Only CC can be stored encrypted by default.

Hi Chris,

In that case is it possible to remove the CVV code label & text input field from checkoutpayment.aspx so that the client can call the customer once order is received to complete the payment over the phone via a credit card terminal?

It seems stupid to include the Credit Card Verification Code: label & CVV input box when processing manual payments does not store the CVV.

Regards,

You can remove the CVV from input. I am having a customer do manual transactions but they're doing it without the CVV. There is a little extra cost but we don't have as much of a legal issue doing it this way. I am just doing this for now but they we will be going to gateway transactions.

I forgot to answer your question, to hide cvv from input, I modified checkout1.aspx and changed ShowCCVerCd to be false:

Code:

ShowCCVerCd="False"

Then I went into appconfig and set CardExtraCodeIsOptional to true.

Hi Chris,

Yes I have advised my client to use a payment gateway ASAP. But for now they want to maximize income by having no gateway/merchant/transaction fees even though the time spent on the phone for manual charging is of course an indirect cost of labour/time.

Thanks for the info regarding removal of CVV numbers!!!

Kind regards,

Originally Posted by chrismartz

To my knowledge, it is not legal to store the CVV code. Only CC can be stored encrypted by default.

It is not illegal to store CVV codes. It has nothing at all to do with the law. It has to do with a businesses contract with Visa/MC and I'm guessing Discover and AMEX also. The contract states you are not to store CVV codes after a credit card has been processed. Basically, you can only retain it long enough to do the capture. Any business found to be doing so can be blacklisted from accepting credit cards. Believe me, this can and does happen. There also stuff in the contract about not putting minimum limits on credit card purchases and also not having different cash prices vs credit card prices.

Let them know that all that has to happen is for one CVV code to be hacked from the system and they will not be able to accept credit cards again. I'm thinking you can't even be PCI compliant if you store CVV codes and PCI compliance is mandatory for accepting credit cards.

Originally Posted by chrismartz

I forgot to answer your question, to hide cvv from input, I modified checkout1.aspx and changed ShowCCVerCd to be false:

Code:

ShowCCVerCd="False"

Then I went into appconfig and set CardExtraCodeIsOptional to true.

Chris,

I cannot find references to ShowCCVerCd="False" in checkout1.aspx. Which version of ASPDNSF do you have running?

I'm running on old version AspDotNetStorefront ML 7.1.0.0

Kind regards,

Originally Posted by MarcJ

It is not illegal to store CVV codes. It has nothing at all to do with the law. It has to do with a businesses contract with Visa/MC and I'm guessing Discover and AMEX also. The contract states you are not to store CVV codes after a credit card has been processed. Basically, you can only retain it long enough to do the capture. Any business found to be doing so can be blacklisted from accepting credit cards. Believe me, this can and does happen. There also stuff in the contract about not putting minimum limits on credit card purchases and also not having different cash prices vs credit card prices.

Let them know that all that has to happen is for one CVV code to be hacked from the system and they will not be able to accept credit cards again. I'm thinking you can't even be PCI compliant if you store CVV codes and PCI compliance is mandatory for accepting credit cards.

Hi MarcJ,

I totally agree with what you are saying. Though I wasn't sure whether it was or was not illegal but thanks for clearing that up. I've just had a good conversation with my client and they have finally budged and have started proceedings to obtain a gateway/merchant account because of the lack of storing CVV codes.

Kind regards,

Your customer might also want to take a look at this:

http://usa.visa.com/download/merchan..._merchants.pdf

Specifically page 8

"*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."

and page 12

"• Avoid CVV2 Storage. All merchants are prohibited from storing CVV2 data.
When asking a cardholder for CVV2, merchants must not document this
information on any kind of paper order form or store it on any database."

and page 41

"A cardholder’s CVV2 may never be stored as a part of order information or customer data. The storage of CVV2 is strictly prohibited subsequent to authorization."

and page 53

"• Do not store CVV2 data–this is strictly prohibited."

and page 60

"• CVV2 storage. The Visa U.S.A. Inc. Operating Regulations prohibit merchants
and/or their agents from storing the Card Verification Value 2 data (security
code printed within or immediately to the right of the signature panel) after
transaction authorization."

and page 130

"Card Verification Value 2 (CVV2)
A Visa fraud prevention system used in card-not-present transactions to ensure
that the card is valid. The CVV2 is the three-digit value that is printed on the back
of all Visa cards. Card-not-present merchants ask the customer for the CVV2 and
submit it as part of their authorization request. For information security purposes,
merchants are prohibited from storing CVV2 data."

So, you get the feeling they don't want you to sore CVV data?

Originally Posted by sasdaman

Hi MarcJ,

I totally agree with what you are saying. Though I wasn't sure whether it was or was not illegal but thanks for clearing that up. I've just had a good conversation with my client and they have finally budged and have started proceedings to obtain a gateway/merchant account because of the lack of storing CVV codes.

Kind regards,

Glad to hear they budged. Just curious, were they manually entering the info in a swipe machine since they didn't have a gateway? A gateway account is definitely the cheaper route to go and a heck of a lot less worry.

Originally Posted by MarcJ

Glad to hear they budged. Just curious, were they manually entering the info in a swipe machine since they didn't have a gateway? A gateway account is definitely the cheaper route to go and a heck of a lot less worry.

Hi MarcJ,

Yes exactly. They were trying to manually process through a swipe machine/terminal. But because the CVV was not included they had to call the customer to obtain the CVV data. I agree running a gateway is a more fluid, professional method of doing business online. The information you provided as did others seemed to spook my customer enough to go with the live gateway .

Thanks again! Regards,

Originally Posted by sasdaman

Chris,

I cannot find references to ShowCCVerCd="False" in checkout1.aspx. Which version of ASPDNSF do you have running?

I'm running on old version AspDotNetStorefront ML 7.1.0.0

Kind regards,

Sorry sasdaman, I'm on v 9. Unfortunately I don't have anything older to look at doing this.

Originally Posted by chrismartz

Sorry sasdaman, I'm on v 9. Unfortunately I don't have anything older to look at doing this.

Hi Chris,

Thanks for all your help! I'm sure I will find something in the old version to comment/delete to remove the CVV from checkoutpayment.aspx.

All the best,

Originally Posted by sasdaman

Hi Chris,

Thanks for all your help! I'm sure I will find something in the old version to comment/delete to remove the CVV from checkoutpayment.aspx.

All the best,

I could be wrong but I think when you turn on the gateway it will automatically not display the CVV box.

Originally Posted by MarcJ

I could be wrong but I think when you turn on the gateway it will automatically not display the CVV box.

Hi MarcJ,

Could be but until we get the new Gateway details & merchant account I really need to capture the CC#, name, expiry etc without allowing the customer to input the CVV as it's rendered useless. Just wondered if there was a way to remove the label & input box plus "what's this" link??

Regards,

Originally Posted by sasdaman

Hi MarcJ,

Could be but until we get the new Gateway details & merchant account I really need to capture the CC#, name, expiry etc without allowing the customer to input the CVV as it's rendered useless. Just wondered if there was a way to remove the label & input box plus "what's this" link??

The only appconfig that I can find is CardExtraCodeIsOptional, but it doesn't remove the fields from the form, just makes them optional. You may have to create your own appconfig value and use it to toggle the display with some extra coding.

What you're looking for appears to be the function InputCardHTML found in ASPDNSFCommon within the Address class.

Hope that helps!

Originally Posted by MarcJ

The only appconfig that I can find is CardExtraCodeIsOptional, but it doesn't remove the fields from the form, just makes them optional. You may have to create your own appconfig value and use it to toggle the display with some extra coding.

What you're looking for appears to be the function InputCardHTML found in ASPDNSFCommon within the Address class.

Hope that helps!

Hi MarcJ,

Do you know if source code is required to achieve what you explained above?

Regards,

Originally Posted by sasdaman

Hi MarcJ,

Do you know if source code is required to achieve what you explained above?

Regards,

Sorry to say, yes it is. You may have to live with saving the CVV for a few days until you can get the gateway up and running. With a gateway setup, you'll still want the users to enter the CVV code, it just doesn't get saved. It gets passed to the gateway to do the authorization.

We actually never retain the CVV code, gateway or not - that's against PCI requirements. Customers can enter the code if you haven't modified the software to remove it, but we clear that out once we don't need it anymore (the cleanup stuff that Mike was talking about earlier in this thread).

Thanks to MarcJ & Scott for clearing this up. If anything this entire problem has given my client the push to move with a gateway/merchant account so all in all I'm happy

Regards,