Okay, so storing digitized credit card information/records is a well documented process when it comes to best practices. I recently got asked how a company can store, retrieve and process physical credit cards. I'm not particularly familiar with PCI-DSS standards

The scenario is this: A hotel wants to be PCI compliant, their servers are all up to scratch and all the rest, but as part of their business, the operate a very active bar/club where guests can start a 'tab'. In order to start a tab, a guest must first hand over a valid credit card. This card is then kept under the counter but is not secured in any special way. Does having this card without access control (any employee behind the bar can access it without generating 'logs') and without any kind of safe storage (not in a safe for example) therefore break PCI compliance?

What would the best way of handling cards like this be in such an environment?

  • 2
    Would anyone who's down-voting like to comment as to why?
    – NULLZ
    Jun 17, 2013 at 23:24

3 Answers 3


For cardholder present transactions, there's very little in terms of physical security within the PCI DSS. Cardholders are responsible for their cards and aren't supposed to hand them over to others for third party storage. What should happen in this scenario to limit the access of all bartenders etc to the card is that a pre-authorisation of $0.01 should be taken from the card and the card returned to the cardholder with their tab number. They can then order from that tab for the evening and pay at the end of the night. If they leave with their card, the bar can charge the card based on the pre-authorisation.

The other way to do this may be for a particular bar staff to be responsible for the cards of the people they're running tabs for so you know who has what card when. This isn't really practical due to shifts and taking breaks so the previous process would be best.


I'm not sure how storing the physical card regards to pci dss, the thing I wonder about is why they would store the card in the first place? The easy thing to do would be swiping the card and storing the details in a computer system. ( assign a CC to a tab) that's how most hotels do it these days.

  • What about chip and PIN though? Wouldn't that break that idea?
    – NULLZ
    Jun 16, 2013 at 11:06
  • Not necessarily, in principle you can't store the CVV number. What you can do is require an advance, store the CVV number, and not yet perform the transaction until the tab is closed. Once the tab is closed you perform the transaction with the updated amount. After this it is imperative that you get rid of the CVV number in the database as CVV numbers can only be stored until the transaction is authorized. Jun 16, 2013 at 11:21
  • 1
    @Lucas Kauffman, you can't store the CVV number, ever: PCI DSS 3.2.2 "the three-digit or four-digit card verification code or value printed on the front of the card or the signature panel (CVV2, CVC2, CID, CAV2 data) is not stored under any circumstance". On the list of rules auditors get deadly serious about, that's near the top.
    – gowenfawr
    Jun 16, 2013 at 15:22
  • @gowenfawr Yes that's why I say that you need to get rid of it. Temporary storage is allowed until the transaction has taken place. This was done because otherwise companies who work with batch transactions would not be able to perform them. Jun 16, 2013 at 15:24
  • @Lucas Kauffman I had understood that in-memory storage is acceptable, but writing to a database (even temporarily) violates 3.2.2. I'm certainly open to being wrong, however, so I'll ask my QSA about it next time I chat with him - it's always nice having hypothetical issues to chat about instead of real issues!
    – gowenfawr
    Jun 16, 2013 at 16:03

While the PCI DSS doesn't specifically call out holding on to a customer's card, it's covered by 9.6, "Physically secure all media." To quote the testing procedures,

9.6 Verify that procedures for protecting cardholder data include controls for physically securing all media (including but not limited to computers, removable electronic media, paper receipts, paper reports, and faxes).

The card itself is a physical media containing cardholder data - think of it as someone faxing you a copy of the card, only without the paper :). "Physically securing" would mean some sort of access control to ensure that only authorized personnel (e.g., staff) and not unauthorized personnel (e.g., barflies reaching over the bar) can get to it. Inside a register drawer might work well, because that's something that's got due diligence protection since it's protecting your cash anyway, and all your staff has necessary access without added disruption.

The card might actually different in that it contains the CVV, which cannot be "stored" as per PCI DSS 3.2.2. But since cards are physically handed to staff constantly (e.g. your waiter takes it to the back to swipe it), obviously that's handled differently with physical transactions. I'm afraid I don't have any insight on the nuances there.

Which leads me to my summary... PCI DSS advice you get here

  1. may be biased towards Card-Not-Present (CNP) transactions, and
  2. PCI DSS advice is only an opinion unless it comes from a QSA.

I would encourage you to think of this as one of those times you need to pay a certified auditor to guide your implementation. (And I think that @AndyMac's suggestion about authorizing some amount and then settling for the full tab amount later is probably the right way to go, although I have no idea how signature is finessed in that situation if the customer leaves without signing - my experience is biased towards CNP transactions.)

  • 2
    In Europe, you'll generally find that you rarely need to give your card to anyone to pay. This is very different to North America. For example, in a restaurant in Europe, the waiter will bring a payment terminal to you to pay at the table rather than take your card away from you. In terms of signature signing, you can usually do a CNP transaction using a payment terminal with the PAN and not the CVV2. The transaction cost is more from the acquirer. As I'm Europe based, I'm not sure about how signature requirements are affected.
    – AndyMac
    Jun 16, 2013 at 18:12

You must log in to answer this question.

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