Dynamics User Group - Archived Forums

The forums in this section of DUG are no longer accepting new post, but you can still get lots of value from the old posts here.
Please visit the active forums to comment/post new questions (choose which product you are interested in):


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?

  • Should I take this lacking response as noone here at the Dynamics User Group have sold/implemented/created a credit card solution since October 2008?

  • Eric,

    I have a solution that addresses all your concerns from PCI compliance to tokenization.  It's a gateway/plugin that is up in the air doesn't change any of the tables in the system.

     

     

  • In reply to Jolie Pavent:

    Hi Jolie,

    I didn't really ask if you had a solution, but how you where dealing with the PCI DSS compliance requirements. Can you tell us that?

  • In reply to Erik P. Ernst:

    Erik,

    The secure gateway the processor has developed, Bluepay, is fully PCI  compliant and does tokenization for the merchant.  The merchant is required on an annual basis to complete an SAQ, answering a bunch of questions on how they run their transactions, do they store cardholder data, are they doing any type of recurring billing and what type of equipment, software or gateway are they using.  By next July there will be equipment that will no longer be compliant and right now we are concerned with merchants that are running older versions of software and using older versions of POS equipment (such as older versions of Aloha, POSI Touch, Micros etc.).  Hope this helps, let me know if you have further questions.

  • In reply to Jolie Pavent:

    Hi Jolie,

    What do you mean with that equipment after next July will no longer be compliant? Why would anyone then select your solution?

    Are you working for Bluepay or a partner? Do they have an addon solution for which Dynamics products?

  • In reply to Erik P. Ernst:

    Erik,

    Equipment I'm referring to is antequated POS terminals not the gateway SaaS solution we provide.  I partner with Bluepay to sell their gateway and provide the merchant account for credit card processing. 

  • In reply to Jolie Pavent:

    Jolie,

    Which of the Dynamics products did you integrate with so far?

Related