I tried asking my bank about this issue by they were not so helpful. Thought I'd try here to see if anyone has had a similar issue.

I own a web hosting company. We currently process all recurring billing on the first of the month. We have a customer portal where our clients can go in and change the credit card they have on file.

The problem is we need a way to verify the CVV security code provided at the portal. The only way to verify is to charge something but this only happens on the first of the month.

Regulations and laws prohibit us from storing the CVV security code anywhere so we need a way to verify the CVV on the portal once the customer hits the submit button.

I have a proposed solution I think that may work. I can do a quick one dollar authorization and then immediately void the transaction. The transaction will never make it to the capture or settle state. (capture and settle means to collect the money. if you let it sit without doing these, the authorization will expire after seven days.)

If the payment gateway says the CVV code is legit, I can discard the CVV and update the database with the new card info. If it comes back as invalid, I can dump the new card info and prompt the customer to re-enter the information.

I'd like to know if this solution is a good idea? Would this work across all card types? (debit cards with visa/mastercard logo for example)

So far, the banks have not been very helpful. They've recommended I get the customer to fax in the back of the card or to photocopy it. Tried my best to explain that would drive all the customers away as I'm a 100% on-line business.

Anyways, I could really use some suggestions here. Fraud in web hosting is just too high and I must verify every card without exception.

Anybody have some previous experiences with this issue? Any alternative ideas?

Your payment gateway must support so called recurring transactions without CVV. You send a flag on an initial transaction saying that the transaction will have recurring transactions in the future. The payment gateway stores the credit card data. When the recurring time comes, you must have an interface to send the recurring transaction without CVV code, just referencing to the parent initial transaction.

Another words, your payment gateway must support such type of transactions.

I have a proposed solution I think that may work. I can do a quick one dollar authorization and then immediately void the transaction. The transaction will never make it to the capture or settle state. (capture and settle means to collect the money. if you let it sit without doing these, the authorization will expire after seven days.)

Better yet, do an Authorization Only (AUTH ONLY) transaction for $1. The customer's card is never charged and you don't have to do a refund (that $1 will be frozen on their card but won't harm them). You still get a CVV response doing that.

stymiee:
This is exactly what I was proposing. It would be an AUTH-ONLY transaction which just freezes $1 in the cardholders account. They never really get charged for it since I never issue a SETTLE on that transaction. I'd VOID that AUTH-ONLY transaction immediately afterwards to release the $1 freeze.

I'd like to know if this AUTH-ONLY approach works on all card types, including debit cards with a visa/mastercard logo.


touol:
The payment gateway I use (Orbital from Chase) does support recurring transactions. My customers have variable billing amounts, however. We offer web design services so the jobs they request are tacked onto their next bill. Its not a fixed rate always so this approach could get a bit unwieldy.

Should work on major-label debit cards, yes.

You might want to check with your provider to see if they are going to charge you a transaction fee for the Authorization. You could also ask your provider for a second MID for rebills only that can run without CVV.

Just keep in mind that the authorizations will probably cost you a fee. And if you have a gateway that will give you a number of free transactions per month, those authorizations will cut into those "free" authorizations.

Should work on major-label debit cards, yes.

Nex: That's what I was hoping. Thanks.


You might want to check with your provider to see if they are going to charge you a transaction fee for the Authorization. You could also ask your provider for a second MID for rebills only that can run without CVV.

BusinessAmerica: You are right. I just checked my rates. They charge 20 cents for every AUTH performed regardless. I think that shoots that plan out of the water. :(

My credit card provider has some options for storing customer profiles. Unfortunately, it does not verifty the CVV code. Recurring billing also does not verify the CVV code.

I would not do a "pre-auth" on them. A lot of people look at their statements online. This pre-auth could be seen and then you would get calls asking why are you "charging" my card.

If they are your customer, you probably have already verified their information previously. Can't you assume they are trust-worthy since they have been with you for XX number of months?

I would not do a "pre-auth" on them. A lot of people look at their statements online. This pre-auth could be seen and then you would get calls asking why are you "charging" my card.

If they are your customer, you probably have already verified their information previously. Can't you assume they are trust-worthy since they have been with you for XX number of months?

As far as I know, an AUTH-ONLY transaction isn't supposed to withdraw the money yet. Its the SETTLE that actually does the debit.

I've tried AUTH'ing my own credit card and it doesn't show up at all. Do debit cards work differently?

As for the trust-worthy part, I'm not really concerned about customers that have been with me for a few months. I'm concerned about customers who have only been with me for less than one month. I won't go into them here but there are some avenues for abuse available in that first month.

Debit cards can vary - first they need to have a logo on them for the card associations that you accept - in the United States, usually MasterCard and Visa.

Also with debit cards, some banks will actually also take the money out of the bank account - so if you auth a dollar, that dollar is taken out of the bank account since it is yours. When the auth expires, the money is given back to the customer.

If it is a new customer who makes a change, add something to your TOS that the billing department will call the user when billing is due. Then the billing department can enter the card number and CVV in the virtual terminal.

Sure it might take a few minutes, but it will protect you in some aspects and even more on a few more.

Another possibility is that you could make it part of your TOS that when a new user wants to change their billing, they simply pay for the next billing cycle upfront (using their CVV) at the time.

This way, you avoid the issues associated with auth-only transactions on debit/check cards, you get the security of the CVV validation and you don't need to incur any direct staff time to deal with it.

You could even possibly add some logic to make this the case for new users (under X months old) but ignore it and allow auto-updates for longer term clients.

Honestly, Don't AUTH the card. You could auth it for a penny, and cost yourself .20, so what's the point in that?

I mean really, what is the point you are trying to accomplish here? Entering in the CVV does not get you a lower rate. It is either Qualified (as in Swiped which yours can never be) or Mid qual (matched AVS and settled in 24 hours) or non-qual (basically just the number)

Having the correct CVV is not going to protect you from a charge back either. Don't be fooled. If the card is stolen, they may still have the correct CVV and it show back up later as stolen and gets charged back. I agree of course, that it is better to verify anything that you can, but in this case, it isn't quite that simple.

Please explain exactly what you want to accomplish by having and verifying the CVV code, other than your own peace of mind in thinking the card isn't stolen.

I'm not convinced in the long run that it is worth you time and effort to go through so much trouble just to verify a CVV.

Also, I believe that you can store a truncated part of the CVV in your database, and store the Other part of the CVV that is hidden from the first part in another location, such as a specialized email box. they have recently updated the rules so this may have changed, and I will double check this because I stick my neck out :-)


Just my two cents, and others may not agree, but it really just depends on what you really want to accomplish...I would just charge the card and move on.

If it is a new customer who makes a change, add something to your TOS that the billing department will call the user when billing is due. Then the billing department can enter the card number and CVV in the virtual terminal.

Another possibility is that you could make it part of your TOS that when a new user wants to change their billing, they simply pay for the next billing cycle upfront (using their CVV) at the time.

These are good ideas. I could also try something a bit different and just send them an e-mail that links to a page if I need to have a CVV verified. They'd click on the link, get some instructions that I need them to enter their CVV, and then charge the card right there.


Honestly, Don't AUTH the card. You could auth it for a penny, and cost yourself .20, so what's the point in that?

Please explain exactly what you want to accomplish by having and verifying the CVV code, other than your own peace of mind in thinking the card isn't stolen.

Also, I believe that you can store a truncated part of the CVV in your database, and store the Other part of the CVV that is hidden from the first part in another location, such as a specialized email box. they have recently updated the rules so this may have changed, and I will double check this because I stick my neck out :-)

Ok, fair enough. I'll explain what I'm trying to avoid here. My overall goal is to reduce fraud on domain orders.

I register domains and most fraud orders I see are from scammers who order a domain. If I get a chargeback, the domain is a big problem. I can not easily reverse these.

There is currently five day grace period on domains that allow them to be cancelled. This helps some but ICANN is currently trying end what's called domain tasting, where the search squatters register a domain and wait the five days to test its profitability. ICANN wants to put an end to this. I'm not sure if that will go through but if it does, it will make a good sized dent in the bottom line.

Overall, I want to reduce fraud on domain orders above all else.

Overall, I want to reduce fraud on domain orders above all else.

Slipped my mind, when writing this but I can think of some ways to offset fraud on domain orders. I could require a CVV to be entered on every domain order. I can also send the customer an e-mail they must click on in order to continue with the order.

Also, my database is structured in such a way that orders are tacked onto a customer's account, and then billed once a month. This includes domain orders. I could separate this and make domains charge separately from the rest of the services.

I'd like to provide one clean and easy bill for the customer. The best way I can roll CVV verification into this format is to do the verification at the customer portal where the card info is first received. If this is not doable, then I have to restructure how things are billed.