4

For a solution that we are developing for the hospitality industry, we need to save customer credit card information, and show this to the hotel for them to manually process the payment later.

I have read all these questions and answers:

  1. Storing credit card information for later manual processing
  2. Storing credit card data on behalf of customers: and transfer the data later

The answer is pretty much "no, you can't do it." But the thing is, this is pretty much how it works within the hospitality industry, and me saying "no, you can't do it" basically means not being able to sell our solution to hotels.

I know many hotel booking engine providers that store the CC information for the hotel to view and process manually. My hotel clients also tell me that even booking.com does this. The catch is, they can only view the credit card information a certain amount of times before it vanishes.

Does this "only viewable a certain amount of time before vanishing" clause change the situation? Is there any way of getting around this to sell solutions to hotels without breaking the law and putting ourselves in danger (apart from processing the money through a payment gateway ourselves, hotels don't want this either)?

hattenn
  • 143
  • 3
  • If some competitors violate PCI-DSS doesn't mean you should. They might be getting away with it *for now* but they'll be in big trouble when the shit hits the fan and those cards end up out there on the black markets. Your best bet is to handle the entire transaction yourself - the hotel staff can decide when/how to take the money while never being exposed to the sensitive data. – André Borie Oct 08 '17 at 10:09
  • Your solution sounds good, but you would need to erase CC data after hotel processes the transaction. This way, you should have only CC data which is in processing queue and nothing historical. So if your databsse got compromised, you'd have only few CC numbers stolen. – Aria Oct 08 '17 at 11:55
  • @AndréBorie, that's precisely why I asked the question, and not went ahead and did it anyways. It sounds very simple to say "handle the transaction yourself" from an IT point of view, but it's not that simple in business. I am not going to be dealing with technical people selling this. As I said, even booking.com is doing this, and considering how many credit cards they process, I don't think they would do it in a way that would put them in danger. They obviously have a way of doing this without putting themselves in danger. – hattenn Oct 08 '17 at 12:44
  • @Aria, that is the method many companies are using, what I want to know is how is it PCI-compliant? As far as I can tell, it shouldn't be, but yet there are even big companies doing it. – hattenn Oct 08 '17 at 12:45
  • 1
    What do you mean by "manually process"? Are you intending to display the card number for them to key into their own payment system? Do they just need to look at the last four and hit a button to confirm it should be charged? Also, the lodging industry is probably the [*least* secure right now](http://www.hotelnewsnow.com/Articles/50937/Timeline-The-growing-number-of-hotel-data-breaches/). So just because people are doing it, doesn't mean it's right. – Bobson Oct 08 '17 at 16:01
  • @Bobson, by "manually process," I mean seeing the credit card number and keying it into their own payment system. This is pretty much how it works in the whole hospitality industry. With all due respect, this is not a question of "right" or "wrong," this is a question of "how." Because even the biggest players in the industry offer this method to their hotel customers. I doubt they would put themselves at risk, so they somehow manage to do it without being liable. I'm just trying to figure out what they are actually doing. – hattenn Oct 08 '17 at 17:46
  • 1
    @hattenn - Thanks for clarifying. The point of my link was that many of them *do* put themselves at risk, and a lot of card numbers have been stolen because of it. That said, the answer in your first link cites PCI: "Do not store sensitive authentication data *after authorization* (even if encrypted)." Until the authorization actually happens (which is by the hotel, not the booking site), you're allowed to store it and stay within PCI... It's not safe, but it's permitted. – Bobson Oct 08 '17 at 17:53
  • @Bobson, that is very interesting, I missed that. Thank you, I will look more into it. – hattenn Oct 09 '17 at 06:11

1 Answers1

2

PCI DSS does not prohibit the storage of the Primary Account Number (PAN). Stored PAN just needs to be protected per PCi DSS requirement 3.

You can also store the CVV2 value at with the PAN until the payment has been authorised, at which stage you must securely delete any stored CVV2. May booking services will do this automatically after the first night of the booking - as the booking company is reliant on the hotel to tell them that the transaction has been authorised.

You can continue to store the PAN as long as you have a justifiable retention policy and it remains protected per requirement 3.

Of course - you will need to comply with PCI DSS and be assessed as a service provider, and you should realise that criminals like companies with repositories of PAN and CVV2 because that's good data to steal - so you (like all such booking intermediaries) will be a target.

BUT these is nothing within PCI DSS that prevents the business model you have described.

withoutfire
  • 1,000
  • 4
  • 7