Webervations V-Code Missing

[Copperhead]

Another option I may consider is charging the full reservation in advance. Then it's all done and I delete the cc info immediately. Maybe not even enter it but write it on a piece of paper and then shred it, or eat it.
We are having to pay an extra $15/month now for 'insurance' that will pay for an audit should we ever have to have one. If the consumer's cc info is stolen, however, we're out of business because the insurance doesn't cover anything but the cost of the audit. And you know darn well that the 'deep pockets' of all the other companies involved will get them off the hook tout de suite, leaving us, the lowly innkeeper with the $10,000 fines and the onus of repairing the consumer's credit rating, etc.
There has to be a better way to conduct business that doesn't involve us even KNOWING the consumer's cc info.
Given the number of guests who cancel whose cards I actually charge (1 in 5 years) it is not worth the worry to me anymore to have the cc info anywhere..

Another option I may consider is charging the full reservation in advance. Then it's all done and I delete the cc info immediately. Maybe not even enter it but write it on a piece of paper and then shred it, or eat it......Given the number of guests who cancel whose cards I actually charge (1 in 5 years) it is not worth the worry to me anymore to have the cc info anywhere.

Yes as I said, I have had 2-3 no-shows in 10 years..but once this policy is commonly known to the public, what difference do you think it will have on the traveler? As of now, we all have policies in place and have had a way to charge IF need be. Having the card on file has been a reassurance for me as well as the guest regarding that room for those dates.

 

[Samster]

Hi gang,
This past week we made significant changes to the credit card security of Webervations. In addition to robust encryption being put into place, we no longer can take CVV codes. Soon we will be releasing auto-delete settings like we have in Rezo GT.
It is flat-out against ALL PCI and Visa rules to store these - so capture of them is pointless and causes any system or user to be non-compliant. We've had two banks in the past two months (People's and First Merit) call us out on this since they both had Webervations users as customers. If you are using a system that captures these (and plenty do), and that system allows you to retrieve them online in any way - that system cannot be PCI compliant - period - so we had no choice. I know of at least two systems out there that claim to be compliant, but allow this to happen - meaning they are knowingly not compliant, regardless of whatever certificate they may show on their website. As an innkeeper if you are using one of them, you are also non-compliant and asking for trouble IMHO.
In most cases having the CVV shouldn't help you get better rates - if your processor is charging you extra by requring CVV, then you might want to look at a different processor.
The number/letter issue is a different story - are you saying that when you go in to retrieve a credit card number in Webervations that it is showing up as letters, not numbers?.

Well, there are obviously snafus in this requirement for all online credit card purchasing. Every single time I purchase online, I've had to enter the V-code. It is a security check for the purchaser that you have the actual card in hand. So, this makes no sense to me at all. If the data is encrypted, there should not be an issue. I think that they are spinning their wheels on this and one hand doesn't know what the other hand is doing. I will agree that there are rez systems that need to update in order to make it easier for you to delete cc info once the card is processed and payment is received by the merchant. Meanwhile, if you have one of the web-based systems, that information is stored on someone else's server and if it's a better one, it's encrypted. Why don't we just stop accepting credit cards and only take cash?

 

[JBanczak]

Keeping the credit card until arrival is fine - Swirt has seen the options we have in Rezo GT - they will be mimicked in Weber - so you choose to keep it, or delete it automatically either X days after taking it, or X days after checkout, etc. We let the innkeeper choose.
I thought we sent out a notification last week - but I will be checking. If we did not, then that was a mistake on our part.
From what I know, CVV should not impact your rate - but processors can give you whatever rate they want in reality - they choose when to downgrade, whether low or mid-qual applies, etc. That is why we only use Tom W and Intuit - both are VERY honest and have the best rates. Here is one article from Braintree on CVV:
[h1]CVV2 Does Not Affect Credit Card Rate Qualification[/h1]Posted on Friday, April 04, 2008 by Bryan Johnson

Most merchants mistakenly believe that processing a cardholder's three or four digit value (CVV2, CVC2 or CID)for a card not present transaction (e.g. ecommerce) will help qualify for lower credit card rates. The CVV2 value is only valuable to protect against credit card fraud and has nothing to do with rate qualification. These three and four digit codes aremost often confused with Address Verification Service (AVS) which can be used to qualify for lower credit card rates.
CVV stands for Card Verification Value and was introduced by MasterCard in 1997 and Visa in 2001. For swiped transactions, the value is referred to as CVV1. Each of the card brands has its own acronym:
Visa: CVV2 - Card Verification Value MasterCard: CVC2 - Card Validation Code American Express: CID Unique Card Code (and 4 digits) Discover: CID Card Identification Number
Merchants are able to configure payment processing systems to accept or decline transaction requests based upon the match or mismatch of CVV2, CVC2 orCIDinformation. So for example, if a merchant creates a rule to decline all transactions where the CVV2, CVC2 orCIDvalue does not match, the authorization request could be successful with the issuing bank, but the transaction will be denied by the merchant. Even though the transaction was denied by the merchant, the consumer's card will still be authorized.
PCI DSS Compliance prohibits merchants from storing the CVV2, CVC2 or CID values. For recurring billing, merchants can accept and validate the code during the initial authorization but cannot store it for additional transactions. After the initial validation, there really is no value in storing it.
Another link on this: http://www.straightpassthrough.biz/what-is-up-with-the-cvv2-code/

 

[JBanczak]

Hi gang,
This past week we made significant changes to the credit card security of Webervations. In addition to robust encryption being put into place, we no longer can take CVV codes. Soon we will be releasing auto-delete settings like we have in Rezo GT.
It is flat-out against ALL PCI and Visa rules to store these - so capture of them is pointless and causes any system or user to be non-compliant. We've had two banks in the past two months (People's and First Merit) call us out on this since they both had Webervations users as customers. If you are using a system that captures these (and plenty do), and that system allows you to retrieve them online in any way - that system cannot be PCI compliant - period - so we had no choice. I know of at least two systems out there that claim to be compliant, but allow this to happen - meaning they are knowingly not compliant, regardless of whatever certificate they may show on their website. As an innkeeper if you are using one of them, you are also non-compliant and asking for trouble IMHO.
In most cases having the CVV shouldn't help you get better rates - if your processor is charging you extra by requring CVV, then you might want to look at a different processor.
The number/letter issue is a different story - are you saying that when you go in to retrieve a credit card number in Webervations that it is showing up as letters, not numbers?.

Well, there are obviously snafus in this requirement for all online credit card purchasing. Every single time I purchase online, I've had to enter the V-code. It is a security check for the purchaser that you have the actual card in hand. So, this makes no sense to me at all. If the data is encrypted, there should not be an issue. I think that they are spinning their wheels on this and one hand doesn't know what the other hand is doing. I will agree that there are rez systems that need to update in order to make it easier for you to delete cc info once the card is processed and payment is received by the merchant. Meanwhile, if you have one of the web-based systems, that information is stored on someone else's server and if it's a better one, it's encrypted. Why don't we just stop accepting credit cards and only take cash?

.

Well, there are obviously snafus in this requirement for all online credit card purchasing. Every single time I purchase online, I've had to enter the V-code. It is a security check for the purchaser that you have the actual card in hand. So, this makes no sense to me at all. If the data is encrypted, there should not be an issue. I think that they are spinning their wheels on this and one hand doesn't know what the other hand is doing. I will agree that there are rez systems that need to update in order to make it easier for you to delete cc info once the card is processed and payment is received by the merchant. Meanwhile, if you have one of the web-based systems, that information is stored on someone else's server and if it's a better one, it's encrypted. Why don't we just stop accepting credit cards and only take cash?

There is no doubt on storing CVV - it can be used in the transaction, but it cannot be kept on a server on file - period. Visa and PCI rules are crystal clear on this - it is one of the main questions even in a self-audit. Any system that stores this is not PCI compliant.

 

[JBanczak]

Another option I may consider is charging the full reservation in advance. Then it's all done and I delete the cc info immediately. Maybe not even enter it but write it on a piece of paper and then shred it, or eat it.
We are having to pay an extra $15/month now for 'insurance' that will pay for an audit should we ever have to have one. If the consumer's cc info is stolen, however, we're out of business because the insurance doesn't cover anything but the cost of the audit. And you know darn well that the 'deep pockets' of all the other companies involved will get them off the hook tout de suite, leaving us, the lowly innkeeper with the $10,000 fines and the onus of repairing the consumer's credit rating, etc.
There has to be a better way to conduct business that doesn't involve us even KNOWING the consumer's cc info.
Given the number of guests who cancel whose cards I actually charge (1 in 5 years) it is not worth the worry to me anymore to have the cc info anywhere..

Another option I may consider is charging the full reservation in advance. Then it's all done and I delete the cc info immediately. Maybe not even enter it but write it on a piece of paper and then shred it, or eat it.
We are having to pay an extra $15/month now for 'insurance' that will pay for an audit should we ever have to have one. If the consumer's cc info is stolen, however, we're out of business because the insurance doesn't cover anything but the cost of the audit. And you know darn well that the 'deep pockets' of all the other companies involved will get them off the hook tout de suite, leaving us, the lowly innkeeper with the $10,000 fines and the onus of repairing the consumer's credit rating, etc.
There has to be a better way to conduct business that doesn't involve us even KNOWING the consumer's cc info.
Given the number of guests who cancel whose cards I actually charge (1 in 5 years) it is not worth the worry to me anymore to have the cc info anywhere.

If I recall Bree, we had talked about this before and I believe you also went through the important step of making sure you were PCI compliant - because the insurance only covers you for the audit if you are compliant.
If someone was using an availabilty system that stored CVV, and that turned up in the audit, then you could not be compliant, and the way the policy is written, you would have to pay for it. So the insurance is only as good as your own compliance is.
Sort of like auto insurance. If you buy it, then let your driver's license expire - the insurance doesn't cover you any more... I'm happy to list the companies that are blatantly not PCI compliant that I know of, but until asked I'd rather not do so.

 

[Samster]

Hi gang,
This past week we made significant changes to the credit card security of Webervations. In addition to robust encryption being put into place, we no longer can take CVV codes. Soon we will be releasing auto-delete settings like we have in Rezo GT.
It is flat-out against ALL PCI and Visa rules to store these - so capture of them is pointless and causes any system or user to be non-compliant. We've had two banks in the past two months (People's and First Merit) call us out on this since they both had Webervations users as customers. If you are using a system that captures these (and plenty do), and that system allows you to retrieve them online in any way - that system cannot be PCI compliant - period - so we had no choice. I know of at least two systems out there that claim to be compliant, but allow this to happen - meaning they are knowingly not compliant, regardless of whatever certificate they may show on their website. As an innkeeper if you are using one of them, you are also non-compliant and asking for trouble IMHO.
In most cases having the CVV shouldn't help you get better rates - if your processor is charging you extra by requring CVV, then you might want to look at a different processor.
The number/letter issue is a different story - are you saying that when you go in to retrieve a credit card number in Webervations that it is showing up as letters, not numbers?.

Well, there are obviously snafus in this requirement for all online credit card purchasing. Every single time I purchase online, I've had to enter the V-code. It is a security check for the purchaser that you have the actual card in hand. So, this makes no sense to me at all. If the data is encrypted, there should not be an issue. I think that they are spinning their wheels on this and one hand doesn't know what the other hand is doing. I will agree that there are rez systems that need to update in order to make it easier for you to delete cc info once the card is processed and payment is received by the merchant. Meanwhile, if you have one of the web-based systems, that information is stored on someone else's server and if it's a better one, it's encrypted. Why don't we just stop accepting credit cards and only take cash?

.

Well, there are obviously snafus in this requirement for all online credit card purchasing. Every single time I purchase online, I've had to enter the V-code. It is a security check for the purchaser that you have the actual card in hand. So, this makes no sense to me at all. If the data is encrypted, there should not be an issue. I think that they are spinning their wheels on this and one hand doesn't know what the other hand is doing. I will agree that there are rez systems that need to update in order to make it easier for you to delete cc info once the card is processed and payment is received by the merchant. Meanwhile, if you have one of the web-based systems, that information is stored on someone else's server and if it's a better one, it's encrypted. Why don't we just stop accepting credit cards and only take cash?

There is no doubt on storing CVV - it can be used in the transaction, but it cannot be kept on a server on file - period. Visa and PCI rules are crystal clear on this - it is one of the main questions even in a self-audit. Any system that stores this is not PCI compliant.
.

Well, then there are numerous people out there that are non-compliant, I'm sure. And to play the Devil's Advocate here, I see no difference in keeping credit card info before the date of reservation for months on end vs. afterwards when it comes right down to it! Jeez....
These crooks will get info if they want it bad enough. That's the bottom line. Cameras at ATMs, fake keypads that capture data, etc.,etc. It goes on & on.

 

[JBanczak]

Hi gang,
This past week we made significant changes to the credit card security of Webervations. In addition to robust encryption being put into place, we no longer can take CVV codes. Soon we will be releasing auto-delete settings like we have in Rezo GT.
It is flat-out against ALL PCI and Visa rules to store these - so capture of them is pointless and causes any system or user to be non-compliant. We've had two banks in the past two months (People's and First Merit) call us out on this since they both had Webervations users as customers. If you are using a system that captures these (and plenty do), and that system allows you to retrieve them online in any way - that system cannot be PCI compliant - period - so we had no choice. I know of at least two systems out there that claim to be compliant, but allow this to happen - meaning they are knowingly not compliant, regardless of whatever certificate they may show on their website. As an innkeeper if you are using one of them, you are also non-compliant and asking for trouble IMHO.
In most cases having the CVV shouldn't help you get better rates - if your processor is charging you extra by requring CVV, then you might want to look at a different processor.
The number/letter issue is a different story - are you saying that when you go in to retrieve a credit card number in Webervations that it is showing up as letters, not numbers?.

Well, there are obviously snafus in this requirement for all online credit card purchasing. Every single time I purchase online, I've had to enter the V-code. It is a security check for the purchaser that you have the actual card in hand. So, this makes no sense to me at all. If the data is encrypted, there should not be an issue. I think that they are spinning their wheels on this and one hand doesn't know what the other hand is doing. I will agree that there are rez systems that need to update in order to make it easier for you to delete cc info once the card is processed and payment is received by the merchant. Meanwhile, if you have one of the web-based systems, that information is stored on someone else's server and if it's a better one, it's encrypted. Why don't we just stop accepting credit cards and only take cash?

.

Well, there are obviously snafus in this requirement for all online credit card purchasing. Every single time I purchase online, I've had to enter the V-code. It is a security check for the purchaser that you have the actual card in hand. So, this makes no sense to me at all. If the data is encrypted, there should not be an issue. I think that they are spinning their wheels on this and one hand doesn't know what the other hand is doing. I will agree that there are rez systems that need to update in order to make it easier for you to delete cc info once the card is processed and payment is received by the merchant. Meanwhile, if you have one of the web-based systems, that information is stored on someone else's server and if it's a better one, it's encrypted. Why don't we just stop accepting credit cards and only take cash?

There is no doubt on storing CVV - it can be used in the transaction, but it cannot be kept on a server on file - period. Visa and PCI rules are crystal clear on this - it is one of the main questions even in a self-audit. Any system that stores this is not PCI compliant.
.

Well, then there are numerous people out there that are non-compliant, I'm sure. And to play the Devil's Advocate here, I see no difference in keeping credit card info before the date of reservation for months on end vs. afterwards when it comes right down to it! Jeez....
These crooks will get info if they want it bad enough. That's the bottom line. Cameras at ATMs, fake keypads that capture data, etc.,etc. It goes on & on.
.

Well, then there are numerous people out there that are non-compliant, I'm sure. And to play the Devil's Advocate here, I see no difference in keeping credit card info before the date of reservation for months on end vs. afterwards when it comes right down to it! Jeez....
These crooks will get info if they want it bad enough. That's the bottom line. Cameras at ATMs, fake keypads that capture data, etc.,etc. It goes on & on.

The difference is that you want to minimize your risk. The safest way is to delete immediately after processing. The truth is that a card-not-present advanced deposit is extremely hard to keep if the customer does a chargeback.
So - for the guests who do show up, you don't need the number... for the guests who are honest - and don't dispute the deposit you don't need the number, and for the guests who are dishonest - they will dispute in any case and you are probably going to give the money back!
But the big difference is that lodging has a justifiable business reason for holding a credit card until departure. After departure, there is no justifiable business reason. That is how the powers-that-be view it, and the rules are clearly set by a higher authority. Our job is to have a certified 3rd party auditor look at our system and make sure they agree we are following the rules.

 

[Samster]

Hi gang,
This past week we made significant changes to the credit card security of Webervations. In addition to robust encryption being put into place, we no longer can take CVV codes. Soon we will be releasing auto-delete settings like we have in Rezo GT.
It is flat-out against ALL PCI and Visa rules to store these - so capture of them is pointless and causes any system or user to be non-compliant. We've had two banks in the past two months (People's and First Merit) call us out on this since they both had Webervations users as customers. If you are using a system that captures these (and plenty do), and that system allows you to retrieve them online in any way - that system cannot be PCI compliant - period - so we had no choice. I know of at least two systems out there that claim to be compliant, but allow this to happen - meaning they are knowingly not compliant, regardless of whatever certificate they may show on their website. As an innkeeper if you are using one of them, you are also non-compliant and asking for trouble IMHO.
In most cases having the CVV shouldn't help you get better rates - if your processor is charging you extra by requring CVV, then you might want to look at a different processor.
The number/letter issue is a different story - are you saying that when you go in to retrieve a credit card number in Webervations that it is showing up as letters, not numbers?.

Well, there are obviously snafus in this requirement for all online credit card purchasing. Every single time I purchase online, I've had to enter the V-code. It is a security check for the purchaser that you have the actual card in hand. So, this makes no sense to me at all. If the data is encrypted, there should not be an issue. I think that they are spinning their wheels on this and one hand doesn't know what the other hand is doing. I will agree that there are rez systems that need to update in order to make it easier for you to delete cc info once the card is processed and payment is received by the merchant. Meanwhile, if you have one of the web-based systems, that information is stored on someone else's server and if it's a better one, it's encrypted. Why don't we just stop accepting credit cards and only take cash?

.

Well, there are obviously snafus in this requirement for all online credit card purchasing. Every single time I purchase online, I've had to enter the V-code. It is a security check for the purchaser that you have the actual card in hand. So, this makes no sense to me at all. If the data is encrypted, there should not be an issue. I think that they are spinning their wheels on this and one hand doesn't know what the other hand is doing. I will agree that there are rez systems that need to update in order to make it easier for you to delete cc info once the card is processed and payment is received by the merchant. Meanwhile, if you have one of the web-based systems, that information is stored on someone else's server and if it's a better one, it's encrypted. Why don't we just stop accepting credit cards and only take cash?

There is no doubt on storing CVV - it can be used in the transaction, but it cannot be kept on a server on file - period. Visa and PCI rules are crystal clear on this - it is one of the main questions even in a self-audit. Any system that stores this is not PCI compliant.
.

Well, then there are numerous people out there that are non-compliant, I'm sure. And to play the Devil's Advocate here, I see no difference in keeping credit card info before the date of reservation for months on end vs. afterwards when it comes right down to it! Jeez....
These crooks will get info if they want it bad enough. That's the bottom line. Cameras at ATMs, fake keypads that capture data, etc.,etc. It goes on & on.
.

Well, then there are numerous people out there that are non-compliant, I'm sure. And to play the Devil's Advocate here, I see no difference in keeping credit card info before the date of reservation for months on end vs. afterwards when it comes right down to it! Jeez....
These crooks will get info if they want it bad enough. That's the bottom line. Cameras at ATMs, fake keypads that capture data, etc.,etc. It goes on & on.

The difference is that you want to minimize your risk. The safest way is to delete immediately after processing. The truth is that a card-not-present advanced deposit is extremely hard to keep if the customer does a chargeback.
So - for the guests who do show up, you don't need the number... for the guests who are honest - and don't dispute the deposit you don't need the number, and for the guests who are dishonest - they will dispute in any case and you are probably going to give the money back!
But the big difference is that lodging has a justifiable business reason for holding a credit card until departure. After departure, there is no justifiable business reason. That is how the powers-that-be view it, and the rules are clearly set by a higher authority. Our job is to have a certified 3rd party auditor look at our system and make sure they agree we are following the rules.
.

My dh works in the credit card authorization biz and he is looking into this in more detail for me. Seems that there are details about the size of biz, where the data is stored, etc. He is of the opinion that some of this is to get extra money out of you for compliance assurance.
I didn't know that the Supreme Being was involved in the credit card biz now. haha!

 

[swirt]

Hi gang,
This past week we made significant changes to the credit card security of Webervations. In addition to robust encryption being put into place, we no longer can take CVV codes. Soon we will be releasing auto-delete settings like we have in Rezo GT.
It is flat-out against ALL PCI and Visa rules to store these - so capture of them is pointless and causes any system or user to be non-compliant. We've had two banks in the past two months (People's and First Merit) call us out on this since they both had Webervations users as customers. If you are using a system that captures these (and plenty do), and that system allows you to retrieve them online in any way - that system cannot be PCI compliant - period - so we had no choice. I know of at least two systems out there that claim to be compliant, but allow this to happen - meaning they are knowingly not compliant, regardless of whatever certificate they may show on their website. As an innkeeper if you are using one of them, you are also non-compliant and asking for trouble IMHO.
In most cases having the CVV shouldn't help you get better rates - if your processor is charging you extra by requring CVV, then you might want to look at a different processor.
The number/letter issue is a different story - are you saying that when you go in to retrieve a credit card number in Webervations that it is showing up as letters, not numbers?.

Well, there are obviously snafus in this requirement for all online credit card purchasing. Every single time I purchase online, I've had to enter the V-code. It is a security check for the purchaser that you have the actual card in hand. So, this makes no sense to me at all. If the data is encrypted, there should not be an issue. I think that they are spinning their wheels on this and one hand doesn't know what the other hand is doing. I will agree that there are rez systems that need to update in order to make it easier for you to delete cc info once the card is processed and payment is received by the merchant. Meanwhile, if you have one of the web-based systems, that information is stored on someone else's server and if it's a better one, it's encrypted. Why don't we just stop accepting credit cards and only take cash?

.

Every single time I purchase online, I've had to enter the V-code.
Yes, you enter it, it goes through the payment gateway for the purpose of that payment and then it is gone...it is used for that payment, then poof. It's not stored.../ can no longer be stored if it was.

 

[JBanczak]

Hi gang,
This past week we made significant changes to the credit card security of Webervations. In addition to robust encryption being put into place, we no longer can take CVV codes. Soon we will be releasing auto-delete settings like we have in Rezo GT.
It is flat-out against ALL PCI and Visa rules to store these - so capture of them is pointless and causes any system or user to be non-compliant. We've had two banks in the past two months (People's and First Merit) call us out on this since they both had Webervations users as customers. If you are using a system that captures these (and plenty do), and that system allows you to retrieve them online in any way - that system cannot be PCI compliant - period - so we had no choice. I know of at least two systems out there that claim to be compliant, but allow this to happen - meaning they are knowingly not compliant, regardless of whatever certificate they may show on their website. As an innkeeper if you are using one of them, you are also non-compliant and asking for trouble IMHO.
In most cases having the CVV shouldn't help you get better rates - if your processor is charging you extra by requring CVV, then you might want to look at a different processor.
The number/letter issue is a different story - are you saying that when you go in to retrieve a credit card number in Webervations that it is showing up as letters, not numbers?.

Well, there are obviously snafus in this requirement for all online credit card purchasing. Every single time I purchase online, I've had to enter the V-code. It is a security check for the purchaser that you have the actual card in hand. So, this makes no sense to me at all. If the data is encrypted, there should not be an issue. I think that they are spinning their wheels on this and one hand doesn't know what the other hand is doing. I will agree that there are rez systems that need to update in order to make it easier for you to delete cc info once the card is processed and payment is received by the merchant. Meanwhile, if you have one of the web-based systems, that information is stored on someone else's server and if it's a better one, it's encrypted. Why don't we just stop accepting credit cards and only take cash?

.

Well, there are obviously snafus in this requirement for all online credit card purchasing. Every single time I purchase online, I've had to enter the V-code. It is a security check for the purchaser that you have the actual card in hand. So, this makes no sense to me at all. If the data is encrypted, there should not be an issue. I think that they are spinning their wheels on this and one hand doesn't know what the other hand is doing. I will agree that there are rez systems that need to update in order to make it easier for you to delete cc info once the card is processed and payment is received by the merchant. Meanwhile, if you have one of the web-based systems, that information is stored on someone else's server and if it's a better one, it's encrypted. Why don't we just stop accepting credit cards and only take cash?

There is no doubt on storing CVV - it can be used in the transaction, but it cannot be kept on a server on file - period. Visa and PCI rules are crystal clear on this - it is one of the main questions even in a self-audit. Any system that stores this is not PCI compliant.
.

Well, then there are numerous people out there that are non-compliant, I'm sure. And to play the Devil's Advocate here, I see no difference in keeping credit card info before the date of reservation for months on end vs. afterwards when it comes right down to it! Jeez....
These crooks will get info if they want it bad enough. That's the bottom line. Cameras at ATMs, fake keypads that capture data, etc.,etc. It goes on & on.
.

Well, then there are numerous people out there that are non-compliant, I'm sure. And to play the Devil's Advocate here, I see no difference in keeping credit card info before the date of reservation for months on end vs. afterwards when it comes right down to it! Jeez....
These crooks will get info if they want it bad enough. That's the bottom line. Cameras at ATMs, fake keypads that capture data, etc.,etc. It goes on & on.

The difference is that you want to minimize your risk. The safest way is to delete immediately after processing. The truth is that a card-not-present advanced deposit is extremely hard to keep if the customer does a chargeback.
So - for the guests who do show up, you don't need the number... for the guests who are honest - and don't dispute the deposit you don't need the number, and for the guests who are dishonest - they will dispute in any case and you are probably going to give the money back!
But the big difference is that lodging has a justifiable business reason for holding a credit card until departure. After departure, there is no justifiable business reason. That is how the powers-that-be view it, and the rules are clearly set by a higher authority. Our job is to have a certified 3rd party auditor look at our system and make sure they agree we are following the rules.
.

My dh works in the credit card authorization biz and he is looking into this in more detail for me. Seems that there are details about the size of biz, where the data is stored, etc. He is of the opinion that some of this is to get extra money out of you for compliance assurance.
I didn't know that the Supreme Being was involved in the credit card biz now. haha!

.

My dh works in the credit card authorization biz and he is looking into this in more detail for me. Seems that there are details about the size of biz, where the data is stored, etc. He is of the opinion that some of this is to get extra money out of you for compliance assurance.
I didn't know that the Supreme Being was involved in the credit card biz now. haha!

LOL - sometimes it seems that only He Himself could have devised all these rules!!!!

 

[Copperhead]

Hi gang,
This past week we made significant changes to the credit card security of Webervations. In addition to robust encryption being put into place, we no longer can take CVV codes. Soon we will be releasing auto-delete settings like we have in Rezo GT.
It is flat-out against ALL PCI and Visa rules to store these - so capture of them is pointless and causes any system or user to be non-compliant. We've had two banks in the past two months (People's and First Merit) call us out on this since they both had Webervations users as customers. If you are using a system that captures these (and plenty do), and that system allows you to retrieve them online in any way - that system cannot be PCI compliant - period - so we had no choice. I know of at least two systems out there that claim to be compliant, but allow this to happen - meaning they are knowingly not compliant, regardless of whatever certificate they may show on their website. As an innkeeper if you are using one of them, you are also non-compliant and asking for trouble IMHO.
In most cases having the CVV shouldn't help you get better rates - if your processor is charging you extra by requring CVV, then you might want to look at a different processor.
The number/letter issue is a different story - are you saying that when you go in to retrieve a credit card number in Webervations that it is showing up as letters, not numbers?.

Well, there are obviously snafus in this requirement for all online credit card purchasing. Every single time I purchase online, I've had to enter the V-code. It is a security check for the purchaser that you have the actual card in hand. So, this makes no sense to me at all. If the data is encrypted, there should not be an issue. I think that they are spinning their wheels on this and one hand doesn't know what the other hand is doing. I will agree that there are rez systems that need to update in order to make it easier for you to delete cc info once the card is processed and payment is received by the merchant. Meanwhile, if you have one of the web-based systems, that information is stored on someone else's server and if it's a better one, it's encrypted. Why don't we just stop accepting credit cards and only take cash?

.

Well, there are obviously snafus in this requirement for all online credit card purchasing. Every single time I purchase online, I've had to enter the V-code. It is a security check for the purchaser that you have the actual card in hand. So, this makes no sense to me at all. If the data is encrypted, there should not be an issue. I think that they are spinning their wheels on this and one hand doesn't know what the other hand is doing. I will agree that there are rez systems that need to update in order to make it easier for you to delete cc info once the card is processed and payment is received by the merchant. Meanwhile, if you have one of the web-based systems, that information is stored on someone else's server and if it's a better one, it's encrypted. Why don't we just stop accepting credit cards and only take cash?

There is no doubt on storing CVV - it can be used in the transaction, but it cannot be kept on a server on file - period. Visa and PCI rules are crystal clear on this - it is one of the main questions even in a self-audit. Any system that stores this is not PCI compliant.
.

Well, then there are numerous people out there that are non-compliant, I'm sure. And to play the Devil's Advocate here, I see no difference in keeping credit card info before the date of reservation for months on end vs. afterwards when it comes right down to it! Jeez....
These crooks will get info if they want it bad enough. That's the bottom line. Cameras at ATMs, fake keypads that capture data, etc.,etc. It goes on & on.
.

Well, then there are numerous people out there that are non-compliant, I'm sure. And to play the Devil's Advocate here, I see no difference in keeping credit card info before the date of reservation for months on end vs. afterwards when it comes right down to it! Jeez....
These crooks will get info if they want it bad enough. That's the bottom line. Cameras at ATMs, fake keypads that capture data, etc.,etc. It goes on & on.

The difference is that you want to minimize your risk. The safest way is to delete immediately after processing. The truth is that a card-not-present advanced deposit is extremely hard to keep if the customer does a chargeback.
So - for the guests who do show up, you don't need the number... for the guests who are honest - and don't dispute the deposit you don't need the number, and for the guests who are dishonest - they will dispute in any case and you are probably going to give the money back!
But the big difference is that lodging has a justifiable business reason for holding a credit card until departure. After departure, there is no justifiable business reason. That is how the powers-that-be view it, and the rules are clearly set by a higher authority. Our job is to have a certified 3rd party auditor look at our system and make sure they agree we are following the rules.
.

My dh works in the credit card authorization biz and he is looking into this in more detail for me. Seems that there are details about the size of biz, where the data is stored, etc. He is of the opinion that some of this is to get extra money out of you for compliance assurance.
I didn't know that the Supreme Being was involved in the credit card biz now. haha!

.

My dh works in the credit card authorization biz ... He is of the opinion that some of this is to get extra money out of you for compliance assurance.

I believe he is right - at least in part! Seems companies are taking some to the cleaners on this PCI compliance insurance - (Insurance, not really!) In an earlier post on this tread, Bree stated "We are having to pay an extra $15/month now for 'insurance' that will pay for an audit should we ever have to have one." My charge is $24.99 ANUALLY!, I just finished doing a cost comparision with another processing company and their compliance charge was $28.80 semiannually, and they told me that they did not mark up this charge. Hmm
Now I heard (or read) somewhere that this charge will vary depending on the processors rating by the powers that be...really not sure if this is reliable information or not. I just find it questionable that the charges can be so drastically different and wonder if there needs to be more regulations placed on these charges.

 

[JBanczak]

Here is the email we are sending out in case you are interested:
Less than four months after the successful transition of the Webervations system, RezOvation is pleased to announce a sweeping set of product enhancements for Webervations 1.0. First on the list, the encryption methods used on all credit cards entered into Webervations have been extended and upgraded to provide a much greater level of security, on par with that used by BedandBreakfast.com and RezOvation GT and Desktop products. A number of additional security procedures were put in place, including the removal of access to credit card information through direct or unencrypted links. Innkeepers can rest assured that their data is now safer than ever --- another step taken to protect the industry from potential theft and fraud.
To add to the security features, effective immediately, Webervations will no longer be accepting or storing CVV or CVV2 numbers as per the PCI compliance guidelines. PCI regulations expressly prohibit the storing of CVV numbers for viewing. Any system that provides this feature to innkeepers is in violation of PCI regulations, and innkeepers who use systems that provide this feature should know that they can be held liable for using non-compliant systems. RezOvation is committed to ensuring that innkeepers have a system that enables them to have both the best security, as well as one that clearly follows PCI guidelines. By the end of May, a new Webervations feature will enable users to customize their credit card retention policies. Innkeepers will be able to choose how long they retain credit card data – they can delete it immediately after a booking is processed or retain it until a guest checks out. This auto-delete functionality is similar to functionality that has been very well received by RezOvation GT users. Innkeepers can hold onto sensitive data as long as they wish; all sensitive data can be deleted automatically based on their specific settings.
Webervations users who are also BedandBreakfast.com members will also be delighted by another new feature: Webervations can now be used to manage rates and inventory, and receive reservations directly from BedandBreakfast.com, Expedia, hotels.com, Kayak, Sidestep, Nextag, and coming this fall, Travelocity! BedandBreakfast.com recently signed an agreement with Travelocity to feature BedandBreakfast.com bookable properties on Travelocity websites, moving one step closer to the goal of getting B&Bs sold on every major online travel directory through a system that is easy for innkeepers to manage. Rates and inventory automatically synchronize across all systems, and reservations show up immediately in the Webervations system. It takes only a few minutes to set up the new feature, and customers who already use the BedandBreakfast.com Online Reservations program can easily switch over and use Webervations for management instead of the BedandBreakfast.com Online Reservations Manager.
Additional improvements to both Webervations 1.0 and 2.0, as well as to RezOvation GT are planned for the summer months and will be announced as soon as they are ready.

 

[swirt]

Keeping the credit card until arrival is fine - Swirt has seen the options we have in Rezo GT - they will be mimicked in Weber - so you choose to keep it, or delete it automatically either X days after taking it, or X days after checkout, etc. We let the innkeeper choose.
I thought we sent out a notification last week - but I will be checking. If we did not, then that was a mistake on our part.
From what I know, CVV should not impact your rate - but processors can give you whatever rate they want in reality - they choose when to downgrade, whether low or mid-qual applies, etc. That is why we only use Tom W and Intuit - both are VERY honest and have the best rates. Here is one article from Braintree on CVV:
[h1]CVV2 Does Not Affect Credit Card Rate Qualification[/h1]Posted on Friday, April 04, 2008 by Bryan Johnson

Most merchants mistakenly believe that processing a cardholder's three or four digit value (CVV2, CVC2 or CID)for a card not present transaction (e.g. ecommerce) will help qualify for lower credit card rates. The CVV2 value is only valuable to protect against credit card fraud and has nothing to do with rate qualification. These three and four digit codes aremost often confused with Address Verification Service (AVS) which can be used to qualify for lower credit card rates.
CVV stands for Card Verification Value and was introduced by MasterCard in 1997 and Visa in 2001. For swiped transactions, the value is referred to as CVV1. Each of the card brands has its own acronym:
Visa: CVV2 - Card Verification Value MasterCard: CVC2 - Card Validation Code American Express: CID Unique Card Code (and 4 digits) Discover: CID Card Identification Number
Merchants are able to configure payment processing systems to accept or decline transaction requests based upon the match or mismatch of CVV2, CVC2 orCIDinformation. So for example, if a merchant creates a rule to decline all transactions where the CVV2, CVC2 orCIDvalue does not match, the authorization request could be successful with the issuing bank, but the transaction will be denied by the merchant. Even though the transaction was denied by the merchant, the consumer's card will still be authorized.
PCI DSS Compliance prohibits merchants from storing the CVV2, CVC2 or CID values. For recurring billing, merchants can accept and validate the code during the initial authorization but cannot store it for additional transactions. After the initial validation, there really is no value in storing it.
Another link on this: http://www.straightpassthrough.biz/what-is-up-with-the-cvv2-code/.

CVV2 Does Not Affect Credit Card Rate Qualification ... The CVV2 value is only valuable to protect against credit card fraud and has nothing to do with rate qualification. These three and four digit codes aremost often confused with Address Verification Service (AVS) which can be used to qualify for lower credit card rates.

This makes more sense. Thanks for sharing that.
It raises the question for me though. Is or can the cvv data analyzed by webervations for validity. For example when a credit card number is entered a checksum is run on it to at least see if the number is semi-valid it doesn't guarantee the card active or in good standing, but at least that it could be a real card. Is there a checksum or something similar that is run on the cvv to make sure it is valid.
I mean when someone books with me online with Rezovation, the Card number and cv number is passed to intuit immediately and I imagine they would decline it if the cv number was faulty (the charge would fail). But with Webervations, since it is really just passing the data on to the innkeeper is there a check of any kind run on the cv number? If not, is there any point in even asking for it, since you are not able to pass the cv number on to the innkeeper anyway?