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)?

  • 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. Commented Oct 8, 2017 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
    Commented Oct 8, 2017 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
    Commented Oct 8, 2017 at 12:44
  • 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. So just because people are doing it, doesn't mean it's right.
    – Bobson
    Commented Oct 8, 2017 at 16:01
  • 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
    Commented Oct 8, 2017 at 17:53

1 Answer 1


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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .