5 ms·

Ask HN: Does storing CC data in the session violate PCI compliance?

8 points by qeorge 17y ago

In our app we wish to show an order confirmation screen between taking the customer's credit card data and processing the transaction. To achieve this, the app would need to store the customer's credit card information in the session while we present the interstitial confirmation screen. This would be the only time card data is ever stored by the app. My question is whether this "counts" as storing card data, in regards to PCI compliance. My instinct is that it would, but I have seen similar payment flows on big-name retailers' websites. As storing CVV2 information is never allowed regardless of the level of PCI compliance, I don't know how they can do this while remaining compliant. So my question is threefold: 1) In regards to PCI compliance, is there a distinction between short term and long term storage? 2) Is there another way to temporarily store sensitive data which is preferable to the session and adheres to the PCI guidelines? 3) Does this require PCI Level 1 compliance? I've put a fair amount of time into Googling this and haven't found a clear answer. As so many of us on HN sell products of some kind online, surely someone here has dealt with this issue before. Thanks for any advice you can provide. If I find a definitive answer, I will be sure to update this thread.

edw519 17y ago
The order confirmation screen only needs to display the last 4 digits. They know the rest. If any of the other digits were entered incorrectly, you'll both find out soon enough.
- qeorge 17y ago
  Yes, but the question is how do you keep track of the real information between the page views? The obvious answer would be session variables, but this still means the data would be stored briefly in the server's memory.
jacquesm 17y ago
Storing CC data anywhere is a huge nono. You use it at the moment you pass it on to your IPSP. No temp files, no database records, no session keys none of that. Read the terms and conditions of your merchant account. Edit: I'm very serious about this, CC companies periodically check the active merchant accounts and will ruthlessly block you if they see you violate these rules. If you do recurring billing this can sting you in an extremely bad way, to lose a few days of income is bad, to have to rebuild your member base from the ground up is orders of magnitude worse. The reasons are simple if there is any indication you store CC data in between pageviews you are literally asking to be hacked. The very best way to handle these issues is to use an IPSP that serves up your final payment page, that way even the form is not on your machine (and so not subject to having a nice little javascript payload embedded in it at some point by some joker that hacks your site). Unless you are planning on being an IPSP you should not attempt to either receive or store CC info.
- qeorge 17y ago
  Thanks jacquesm. I'm somewhat familiar with PCI standards, and your answer is what I suspected. However, it doesn't totally answer my question, because confirmation screens are quite common. Even meeting PCI Level 1 compliance, and thus being allowed to store the acct #, cardholder name, and expiration date, its still not kosher to store the CVV2 number or track data, so how are others pulling this off? I know some gateways will run cards without the CVV2 #, but the fees are usually higher. Is the answer then that order confirmation screens and sending CVV2 data are mutually exclusive to all merchants, regardless of their bankroll? Edit: Unless you are planning on being an IPSP you should not attempt to either receive or store CC info. This seems a bit extreme. Are you saying no one should build any sort of on-site payment processing into their own site? We build a lot of e-commerce sites for clients, and our standard MO has been to send the data to the gateway immediately and never store it. With SSL and PCI Level 4 compliance, this hasn't been a problem. In this particular case, a desire for a confirmation page was voiced and we at first sought to examine whether or not this would require Level 1 compliance. Upon digging deeper, I'm now of the opinion that its not possible, even with Level 1 compliance, yet I see this in the wild all the time. What gives?
  - andymism 17y ago
    One thing you can try is to submit the credit card information as an Authorization Only transaction first. Most gateways will respond with a transaction id that you could then resubmit after confirmation from the user as a Prior Authorization and Capture transaction that would complete the transaction. Authorization Only transactions and their transaction ids expire after a set period of time if they're not submitted for capture (e.g., 30 days for authorize.net). You won't ever have to store actual credit card information in this scenario (just transaction information) and you can freely show the the last 4 digits of credit used. That's one solution I can think of, but if you can dig up a PCI compliant method to actually store the data, please share.
    - qeorge 17y ago
      That's a really good idea Andy, and the gateway we're using in this particular case is primarily designed for restaurants (MercuryPay) so this would be commonplace for them. I wonder though if its a faux pas to run the card at all without confirming first. I would be fairly upset if a merchant authorized my card (resulting in a hold) and I didn't complete the purchase, but if the authorization is for a short enough time I think this would be OK. Also, a key function of the confirmation page is to minimize the number of invalid requests sent to the gateway, as too many bad requests can cause them to raise the rates. I'm starting to think there is no PCI compliant way to store a CVV2 for any period of time whatsoever, but I'm also incredulous that so many brand name merchants would so wantonly violate the policy. Perhaps with enough volume and Level 1 compliance the gateway will make an exception.
jawspeak 17y ago
I've heard of companies having an internal policy: if in memory (in their data center's control) PCI sensitive data was allowed. In some cases (memory mapped files) it could persist to disk, so either encryption, or a Compensating Control Document was created (limiting access to the filesystem).
adelle 17y ago
Use Javascript to change the caption of the submit button from "OK" to "Confirm" the first time it is pressed and then submit the form on the second press. That way, the data doesn't reach your server until the user has confirmed the purchase.

jacquesm 17y ago
This is getting long :) Feel free to email me by the way. Tegarding the 'auditors', mistakes are made, it happens and not all audit rounds are equally good. Some are downright ridiculous (telling you to change stuff the previous audit told you to do). I don't think it is appropriate to advertise any IPSPs here, the biggest things to look at are segregated merchant accounts, how long have they been in business, hold back period, fees, integration capabilities, customer service department reputation and references. Roughly in that order. It also helps if they process a sizable volume so that when there is a problem it is not just your problem. Masking your own URL is the one thing that always seems to come up as a 'desirable' because nobody likes to send the customer elsewhere at the moment of making the sale. But in practice it doesn't really matter much, as long as you get editorial control over the content of the landing page on the IPSP side and the customer is aware that a transition is going to happen and they get back to where they were on completion of the transaction. The latter is very important. If your IPSP can not give you that sort of functionality then it might be problematic, it could cost you sales. Using your own SSL certificate is not going to be enough to mask the IPSPs URL, after all, once the data captured gets posted you are on their domain anyway. I personally prefer to have the transition happen at the same moment you go from unencrypted to encrypted, that way you sort of guide the customer to the very last step before the payment happens. Depending on your environment that means they've filled up their cart or selected the type of subscription they wish to purchase and then the next click will take them to the 'checkout' where their payment information is captured. I agree the repost seems wrong, but the good news here is that if you are in https anyway then caching is not your problem. No browser or proxy will cache that stuff, if it has passed there once during the post it might as well pass twice more, no harm done. The only thing that is vulnerable to is mitm and by that time that has already happened, the only difference being that your mitm now has three copies of the data instead of just one.
- qeorge 17y ago
  IMHO, eliminating any potential source of confusion from a checkout flow is worth doing, and so masking the domain is usually worth it. And although we know it doesn't make a difference in practice, customers and clients don't like it. Your point about SSL and mitm makes sense. I'll look into the idea of temporarily storing the data in hidden fields, and if I find anything definitive I'll be sure to update. Thanks for the followups, I greatly appreciate your help. If I have further questions I will email you.
  - jacquesm 17y ago
    You're welcome.