swa66 - 10:14 pm on Nov 12, 2012 (gmt 0)
To try to set you on the right track:
See page 6 of https://www.pcisecuritystandards.org/documents/navigating_dss_v20.pdf
The primary account number is the defining factor in the applicability of PCI DSS requirements. PCI DSS requirements are applicable if a primary account number (PAN) is stored, processed, or transmitted. If PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply.
You are transmitting the PAN (credit card number), even storing part of it. So the PCI DSS applies.
Now the PCI DSS standard applies to banks, credit card processors, and merchants (and probably a few more). So you see a lot in there that you can get around and make it easy on yourself by not storing it (or part of it).
In fact in PCI documents you see often the phrase: "Cardholder dataóif you donít need it, donít store it!". Don't shoot yourself in the foot by trying to store things you do not absolutely have to store.
[Moreover PCI DSS requires you to have good reasons and prohibits storing certain data at all]
Secondly it's important to minimize the scope. You can do this by isolating what machines you use to transmit credit card data or are related to it. Now it's not an easy exercise to isolate it, but you should do your very best to get it as if you don't you end up with all IT equipement being subject to strict rules (wich drives up the cost of IT by a serious factor).
Personally: I'd go for a solution where the customer interacts with the processor and I just point them in the right direction, and get a "success + tracking number" back from the processor. That way I neither transmit, process nor store anything and I'm not subject to PCI DSS.
If you have to do things, remember the minimal approach, and you probably can do a self-assessment to claim to be in compliance -do not lie, there are consequences- , but process enough and you'll get an auditor that's going to scrutinise it all.