Offline Credit Card Processing and CVV codes.

[gaugesteve]

I now am aware that storing CVV (security) codes is illegal. But ive ran into a problem, I am opting to use offline processing, simply because its way cheaper, but If i cant gather the cvv code when they are ordering im not able to process the order. Anyone know any offline processors that will not require a cvv code to process the order, or any other work arounds?

 

Thank you in advance,

Steve

http://gaugehosting.com

[spectrumhosting]

Did u find a solution for this?

[verdictjosh]

The problem is that most of the time the merchant can process a transaction for the first time without the cvv number however after that it seems the bank declines it without the cvv number.

 

So it's just better if you use a third party and fork out the loss of 2 - 3% per payment.

[spectrumhosting]

ok .. I find this all a bit stupid ..

 

why does the system allow the customer to enter these details if it can't save them?

 

shouldn't it be removed at this level, not the "behind the scenes" level ..

[bear]

It's collected because of the online processors. One form for all, though I agree it would be decidedly better if that field was removed for offline card entry altogether.

To then store this CVV value would put the customer's data at risk, as well as the processor and WHMCS (for facilitating it) at risk for fines and potential prosecution.

[No-Server]

What if you store them into a temporary database which gets printed by a cronjob on a officeserver every x hours?

[scurrell]

What if you store them into a temporary database which gets printed by a cronjob on a officeserver every x hours?

 

Doesn't matter if you store them for 5 minutes or 5 years - it's illegal

[bear]

Exactly right. That value isn't allowed to be stored, printed or saved. It's meant to be a one time verification, at the time of purchase, after which it is discarded.

[BobC]

Exactly right. That value isn't allowed to be stored, printed or saved. It's meant to be a one time verification, at the time of purchase, after which it is discarded.

 

So how is it obtained for subsequent orders (or for the first order for that matter)? My processor requires it each time. I just performed a test order and the system did ask me for it, but it is not passed on to me when I do the Offline CC Processing. Do I have to call my customers each time to reask for the code? Also, why doesn't WHMCS collect the "Name on the Card" which almost everyone asks for when processing credit cards?

[bear]

Your processor is treating every order as "card not present" and a "once off" payment, so they require the verification code. Third party processors ask for it the first time, and if it passes, consider any future purchases (using the same method and product, at least) as valid using the existing info. If the card changes or a new one is issued (as in expiring), it would need a new one. If you ask your processor and explain the recurring nature of this, they might be willing to work with you including it only once for cards that have not changed. You'd have to contact them to get it, but just the once. Storing it, even written down, could cause you huge liability.

 

It was this and the available reverse decryption necessary to manually process cards that helped convince me not to process that way. I found the risk unacceptable and instead went with a third party processor for cards (several, in fact). It adds to overhead, but decreases risk for the customer and my business. That's important. I don't offer absurdly cheap services or compete on price, so the overhead doesn't hurt as much. Also important.

[BobC]

Your processor is treating every order as "card not present" and a "once off" payment, so they require the verification code. Third party processors ask for it the first time, and if it passes, consider any future purchases (using the same method and product, at least) as valid using the existing info. If the card changes or a new one is issued (as in expiring), it would need a new one. If you ask your processor and explain the recurring nature of this, they might be willing to work with you including it only once for cards that have not changed. You'd have to contact them to get it, but just the once. Storing it, even written down, could cause you huge liability.

 

It was this and the available reverse decryption necessary to manually process cards that helped convince me not to process that way. I found the risk unacceptable and instead went with a third party processor for cards (several, in fact). It adds to overhead, but decreases risk for the customer and my business. That's important. I don't offer absurdly cheap services or compete on price, so the overhead doesn't hurt as much. Also important.

 

I think you missed what I said. I cannot even get the CVS code to begin with. While the system prompts the customer for it, it is not passed to me when I manually process the charge. So I have to call the customer to get that information again (very poor way of dealing with orders and very frustrating to both me and my customers) as well as the Name that appears on the card (used for validation purposes by the third party processor).

[bear]

Missed it? No, I referred to it here: "You'd have to contact them to get it, but just the once."