ISTech Support Forum

ISTech Support Forum
http://www.istechforum.com/YaBB.pl
Evo-ERP and DBA Classic >> Suggestions for Updates >> Credit Card Encryption Reverse / Warning
http://www.istechforum.com/YaBB.pl?num=1144093212

Message started by jhepola on 04/03/06 at 11:40:12

Title: Credit Card Encryption Reverse / Warning
Post by jhepola on 04/03/06 at 11:40:12

Situation where a company uses a Crystal Report to read it's Credit Card numbers. Obviously the encryption has altered this ability.

1) It would be nice if AR-T asked for a confirmation to proceed with this encryption process--it wasn't clear that running this program would do this.

2) Now that the data is encrypted is there a tool to reverse this?

3) Or, is there a report/query in DBA/EVO where I can list current SO's and the CC info. regarding these?

Thanks,

Title: Re: Credit Card Encryption Reverse / Warning
Post by JNAPIER on 04/03/06 at 12:39:56

It is a matter of privacy and security to have that data encrypted. It is in violation of your Merchant Account to store ANY CC info other than encrypted.

John

Title: Re: Credit Card Encryption Reverse / Warning
Post by Lynn Pantic on 04/03/06 at 17:40:50

True enough, John, that's why we did it. But that said, there obviously needs to be a way to get it back out so that charges can actually be run. AR-T can see them one at a time, but what other options are both desirable and meet the merchant agreements?

Title: Re: Credit Card Encryption Reverse / Warning
Post by David Waldmann on 04/04/06 at 03:30:10

I'm not sure how the encryption works.

I currently print the credit card info on what DBA thinks is an Invoice (heavily modified SOF form that has only the pertinent info needed to process a charge). I also print the last 4 (or 5, in the case of AMEX) digits of the card number on the real invoice that we send so the customer knows what card they used. Will this still work with the encryption, or can you only read the numbers in the new AR-T? Also, is that the only place you enter them now, as opposed to in CM-A?

Title: Re: Credit Card Encryption Reverse / Warning
Post by Lynn Pantic on 04/04/06 at 06:41:08

SD-Q controls whether they can be seen in AR-A, CM-A, Neither or Both. If the viewing in AR-A and/or CM-A is disabled, then you can see that a card is on file (************1234) and the expiration date.

If access in AR-A or CM-A is disabled, then you can't save them either. We could change that, what do you think?

Title: Re: Credit Card Encryption Reverse / Warning
Post by David Waldmann on 04/05/06 at 06:40:25

Lynn Pantic wrote:

If access in AR-A or CM-A is disabled, then you can't save them either.

What does that mean? ???

I guess I should install the update so I can get a better handle on what's there and how it works, but what is the suggested/required method to get the info for processing? Also, how is the CVV2 handled?

Title: Re: Credit Card Encryption Reverse / Warning
Post by JNAPIER on 04/05/06 at 06:48:18

Currently you have to view the customer to get the # and their is no CVV2 field. We use IC Verify software for CC processing. It has its own encrypted database so we really have no need to store them in DBA.

John

Title: Re: Credit Card Encryption Reverse / Warning
Post by David Waldmann on 04/05/06 at 10:42:09

John,

I have looked at several stand-alone PC based systems and had narrowed it down to IC Verify, but haven't bitten the bullet on it yet.

How do you (or anyone) handle CVV2s? I have found that sometimes the CC will not be approved without it, so I feel like we need to get it.

Title: Re: Credit Card Encryption Reverse / Warning
Post by JNAPIER on 04/06/06 at 06:20:55

IC Verify is great. No dial-up, connects through your DSL. It has both CVV2 and Address verification. It will approve without either but our rates are better if you have both correct. Encrypted database for all your customers info.

John

Title: Re: Credit Card Encryption Reverse / Warning
Post by David Waldmann on 04/07/06 at 06:46:04

JNAPIER wrote:

It has both CVV2...

I thought the regulations required that you couldn't keep it on file?

Title: Re: Credit Card Encryption Reverse / Warning
Post by JNAPIER on 04/07/06 at 07:15:01

David Waldmann wrote:

I thought the regulations required that you couldn't keep it on file?

That is probably correct. IC Verify doesn't have a field for CVV2 in the customer database.

John

Title: Re: Credit Card Encryption Reverse / Warning
Post by David Waldmann on 04/10/06 at 13:20:08

JNAPIER wrote:

IC Verify doesn't have a field for CVV2 in the customer database.

Is there an "extra" field that you use, or....?

Title: Re: Credit Card Encryption Reverse / Warning
Post by JNAPIER on 04/10/06 at 13:51:42

David Waldmann wrote:

Is there an "extra" field that you use, or....?

It is in the transaction screen when you enter a charge. You put it in for every transaction. It will not save it. We have a separate Excell sheet that very discretely saves this info. No mention of Credit Card, CCV2 just our own internal way of saving it. You would see 7147862354-0879-656. Cust code, last 4 digits of card and CCV2. I hope we are still legal with this method.

John

Title: Re: Credit Card Encryption Reverse / Warning
Post by jhepola on 04/11/06 at 08:48:18

Back on my original question:

Does EVO give the ability for me to customize a report that would show all open SO's in a listing and include the customer's credit card number?

Also, I'd like this for Invoices.

Title: Re: Credit Card Encryption Reverse / Warning
Post by JNAPIER on 04/11/06 at 09:56:40

jhepola wrote:

I would question if it is legal to do so. I know in IC Verify, I can't print out ANY of our customers CC #'s Everything is truncated when printing anything.

John

Title: Re: Credit Card Encryption Reverse / Warning
Post by David Waldmann on 04/12/06 at 04:39:40

JNAPIER wrote:

You would see 7147862354-0879-656. Cust code, last 4 digits of card and CCV2. I hope we are still legal with this method.

From http://usa.visa.com/business/accepting_visa/ops_risk_management/card_not_present.html?it=search#anchor_4

To protect CVV2 data from being compromised, Visa U.S.A. Inc. Operating Regulations prohibit merchants from keeping or storing CVV2 numbers once a transaction has been completed.

I'm just trying to find a good methiod of complying with it. The only thing I can think of is to use something like IC Verify and do a pre-auth on every sale - get the CVV2 from the customer when they order and enter it directly into IC Verify for that transaction. There are two major hangups for us on that idea. One is the time factor - we often have orders that won't ship for several weeks after we take the order. Doesn't the pre-auth expire in a few days? Also, we need to know that the customer pays by credit card so that we can get the CVV2. We don't currently enter orders directly into DBA, so we'd either have to start (which would be a huge problem for us to overcome, procedure wise) or we have to call each customer back who uses a CC. The fact that I can't think of any reasonable way to do it has prevented me from attempting it.