I am in the middle of setting up an ecommerce solution on a commercial website. My system will store card number in the form of : xxxx-xxxx-xxxx-4000 (just the last 4 digits) and XXX (nothing) for the CVV code. The full details are sent to an external gateway (raven).

I would just like to know what level of PCI DSS compliance I require for my servers end.

Below shows maybe 4 different levels of security options.


Kind regards,

  • 2
    If you can in any way avoid taking the credit card data yourself, everyone involved will thank you. PCI compliance is not to be taken lightly and carries continuous costs and continuous independent assessments. One of the reasons it exists is to make the option of using your merchant bank's existing online solution more attractive.
    – Cheekysoft
    Commented Jan 24, 2012 at 15:45
  • Am i correct in thinking the only possible way for this is to not let the client enter there card details into my forms, but to have them redirected to a card processors website entry form?
    – mr12086
    Commented Jan 25, 2012 at 9:28
  • You will have to either (a) redirect to the remote enter-card-details page [my preferred solution if I can cobrand the page]; or (b) embed it as an iframe [my preferred solution if the bank doesn't frame-bust and doesn't allow you to co-brand the pay page]. Many bank's products, can be made to feel pretty seamless. Arguably, the user may trust a major bank more than your organisation, too.
    – Cheekysoft
    Commented Jan 25, 2012 at 12:07
  • Also fear the fines: "Visa determined that the total cost of the liability for [the small Utah family restaurant's] non-compliance was $1.33 million, but ultimately set the fine at $55,000." --An interesting legal countercase has ensued wired.com/threatlevel/2012/01/pci-lawsuit
    – Cheekysoft
    Commented Jan 25, 2012 at 12:13

1 Answer 1


PCI-DSS requires you to be compliant if you store, transmit, or process credit cards. Although you are not storing them in full, does the full credit card number ever reside (even temporarily) on your site? If so, you are subject to the SAQ-D.

The only level (singular) you potentially qualify for is the SAQ-A which deals with merchants who have ecommerce or mail/telephone order transactions.

SAQ-A states

  • Your company handles only card-not-present (e-commerce or mail/telephone-order) transactions;
  • Your company does not store, process, or transmit any cardholder data on your systems or premises, but relies entirely on third party service provider(s) to handle all these functions;
  • Your company has confirmed that the third party(s) handling storage, processing, and/or transmission of cardholder data is PCI DSS compliant;
  • Your company retains only paper reports or receipts with cardholder data, and these documents are not received electronically; and
  • Your company does not store any cardholder data in electronic format.

SAQ-B is for merchants who use card-reading devices.

SAQ-C is basically for businesses that use Point-of-Sale computing systems or virtual terminals.

SAQ-D is for everyone else.

It sounds like card details are entering your system. Even though your intentions are to use a third party processor, this is not the intention of SAQ-A. SAQ-A is meant for third-party processing such that the card details NEVER enter your system (think Paypal).

  • Thanks for the reply, Yes the data is going to be on our system, as the data is entered into forms on our website which is then saved to our DB in the formats listed above and the full data is sent to the card processing company. But I assume as the data is entered into our forms it will therefore be present in post variables, and in the variable passed to the api. Sounds like we will need to meet SAQ-D :S
    – mr12086
    Commented Jan 24, 2012 at 14:50

You must log in to answer this question.

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