

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

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.<p>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.<p>So my question is threefold:<p>1) In regards to PCI compliance, is there a distinction between short term and long term storage?<p>2) Is there another way to temporarily store sensitive data which is preferable to the session and adheres to the PCI guidelines?<p>3) Does this require PCI Level 1 compliance?<p>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.<p>Thanks for any advice you can provide. If I find a definitive answer, I will be sure to update this thread.
======
jacquesm
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
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
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
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.

~~~
jacquesm
The customer should not normally see any started but not completed
transactions, but there have been cases where this data did become visible
leading to lots of confusion.

Confusion = Chargebacks.

So you have to make really sure that there is no way the fact that you did
that gets back to the customer.

Are you doing your own scrubbing ? Or do you purchase a scrubbing service from
the gateway provider ?

The gateway is not the one that decides if you can store CVV2, the card
companies make that decision. The rules for that are available, it's a fairly
strict standard though.

Encrypted harddrives, all kinds of physical security.

I'm guessing that that is the reason why you see big name merchants do this,
but hardly any little ones.

I know of one company that actually set up an IPSP just for that purpose. They
now make more money on that part of their business than on the original
business...

------
jawspeak
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
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.

------
edw519
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
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.

