My site does subscription billing of changing amounts. So my plan is to have my credit card page receive the credit card / PAN info, then store it to CIM. But even though the PAN data will never be stored on my system (including log files, etc) it appears that I'll still need to go through the PCI hoohaw since my site is processing the POST from the credit card form.
As an alternative, anyone know of a service where my site can tell the service (programmatically) to collect the credit card info (PAN), store it in CIM, then give my service the CIM access number for the card's data?
The idea is that the service would deal with the PCI issues. I wouldn't have to since the PAN data would never come near my systems.
Maybe this could be a business idea for Authorize.net?
This would be similar to what Amazon Flexible Payments Service does with their "Co-branded UI Pipeline." See http://docs.amazonwebservices.com/AmazonFPS/2008-09-17/FPSGettingStartedGuide/ (Then click Step 1 on the left side frame)
We've had this discussion elsewhere, and opinions vary. Mine is that as long as you do not store the card information (PAN and especially CVV), and take care to protect the customer data as it is being processed through your system (be aware of the PHP "register_globals" setting, for example), you can use CIM and meet PCI standards. Others seem to feel that the only way to meet PCI is to hand off everything to someone else.
I used to agree with your more lenient philosophy. I note that the cover page of the SAQ Part C --
has the subtitle "Payment Application Connected to Internet, No Electronic Cardholder Data Storage"
But....some merchant account providers are now starting to specifically ask about any software that sees the card data (even if it is not stored). And if the sw is not a "Validated Payment Application" then you are sent to "Part D-land."
I think this issue will become stronger, not weaker, in the future.
I am going by what I read at pcisecuritystandards.org, not sites from consultants who have a vested interest in selling services. A properly implemented web store does not store the PAN anywhere - it passes it on using encrypted channels between the user's browser and the web server.
I think the "co-branded UI pipeline" looks like a spiffed up SIM. I've seen you can create ARB from a transaction via the merchant terminal. I can't see why there couldn't be an option to auto-CIM all customers who pass through SIM. Then you could do additional business logic without storing, processing or transmitting the PAN.
Just like CIM, the "co-branded UI" gives up brand and design to some degree. A cost of staying completely hands-off.
At one point I had allowed myself to believe an off-the-cuff or out-of-context comment that seemed to say no PAN, no PCI but I have since come to the same conclusion as you after re-reading PCI DSS v1.2.1 July 2009 Page 5: "PCI DSS requirements are applicable if a Primary Account Number (PAN) is stored, processed, or transmitted. If a PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply."
I still want to do CIM. It appears to be reasonably priced for the risk reduction and PCI DSS scope reduction it can offer to our environment.
Yes, I agree with you, thank you for the better citation. Plus, it makes complete sense that the card data is at risk if it ever passes through a server. (Eg if the server was compromised then the card data from ongoing transactions would be at risk, even if it wasn't stored on the server.)
Of course, I don't plan on putting the data at risk, I'm following all the right practices. But the idea of DSS is to formalize the right practices.
From what I'm seeing from the banks/card associations, the above is slowly dawning on them. I think the current techniques will be okay for maybe another 12 months or so, depending on your volume and your bank.
But the day is clearly coming when your server will need to pass part D requirements, or only use "certified" software if the card data is ever received by your server.
From other sources, I'm getting the feeling that Authorize.Net is starting to realize this issue. Hopefully they'll come up with an answer. It's clearly technically feasible, they just need to develop the product. -- As you say, probably as an add-on to CIM.
Hi, is there any update in the law with this? I'm in the same situation, and i want to be sure if we need to take extra steps for PCI just for letting the CC be trasmitted via post to our server and then to CMI via API (always using HTTPS and not processing the CC number)
Yes, there is now an option in the CIM api that enables you to have the PAN (card data) sent directly from your customer's web browser to the Authorize.net system.
This means that the card data never enters your own server (not even for a millisecond in transit). So your server should be "out of scope" for PCI.
I think the new protocol is defined in an appendix to the CIM api manual--I don't have time to research it for you now.
It is important for all new CIM apps to use the new protocol to minimize PCI exposure. Old apps should also be converted.
I just re-read your post. The PCI rules haven't changed. If the card data is POSTed from the customer's browser to your server then your server is in scope for PCI.
How much attention your server and your situation gets from the PCI people depends mostly on your card dollar volume and whether you hire a Qualified Security Organization to check out your system.
It's called hosted CIM. You still create the customer profile, and perhaps shipping profile, the old way, but the billing profile is done using either a redirect or an iframe popup, so the credit card data goes direct to Authorize.net.