This discussion has been locked.
You can no longer post new replies to this discussion. Posts are automatically locked, when no new replies have been made for a long time. If you have a question you can start a new discussion.

PCI DSS 1.2 Compliance and Tokenization - How to handle credit cards in Dynamics?

Last week I asked about PCI compliant add-ons for Navision

But diving deeper into this issue has just made me ask a lot more questions. Basically I'm in doubt how many consultants working with credit card solutions to Dynamics (not only Navision - does also apply to Axapta and Great Plains etc.) are really aware about the complex standards made by PCI which all companies accepting credit card payments MUST APPLY TO.

The PCI DSS applies to all entities that store, process, and/or transmit cardholder data. It covers technical and operational system components included in or connected to cardholder data. If you are a merchant who accepts or processes payment cards, you must comply with the PCI DSS.

The rules are not only for US companies but applies to all companies accepting VISA or the other major credit cards. Each brand then again have their own program for compliance and validation levels and enforcement.

So if you're accepting and handling credit card payments in your company then this is important for you and you must comply with it.

Before October 2008, with PCI DSS version 1.1, the levels of security rules you had to apply to was set based upon how many transactions you where handling per year per credit card brand. But with the changes in 2008 it's now based upon the business situation of the merchant (the company receiving credit cards).

Many (most?) companies are able perform a so-called Self-Assessment Questionnaire (SAQ), which means that their business is not required to have a full scale PCI security audit by a qualified security assessor (QSA).  Instead they can handle a number of questions in the questionnaires and have a network / system scan done by an approved scanning vendor (ASV).

The basic question: Are you storing credit card information in Dynamics?

If you are then you cannot use the rules for the Self-Assessment Questionnaires - instead you need to go through a full PCI audit using a qualified security asssessor. The rules you need to apply to now are very though - not only do you need full database audit logs on all tables (ok this can be done automatically by SQL) - but you also need full video surveillance of your servers (both direct servers and connected servers) and a roling program for changing all passwords (both end-users, admins and servers).

All in all this a very expensive setup that you must apply to even if you're only receiving a few credit card payments per year.

What are the alternatives?

Besides from using manual terminals which you can use and a receipt that you then again manually (not electronically) can attach to your invoice copy, then the only alternative I have found so far is tokenization.

What is tokenization?

Tokenization means that you are never storing your customers credit card numbers directly in the system. Instead you are  sending the CHD (card holder data) directly to your payment gateway (I have not found any payment processors who are directly supporting tokenization yet). The gateway will then after the authorization from the payment processor store the CHD in their own system (which is approved by the PCI) and return only a token to the merchant. The token is NOT just an encrypted credit card number, but an unrelated id, which the merchant can use and store in their system for later use also.

My questions to all of you:

Are you aware of the PCI standards and what they means to companies receiving credit card payments?

And what have you done about it?

Are you still storing full credit card data in the database or are you using tokenization?

Related
Recommended