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).
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.
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.
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.
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?
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.
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?
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.
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?
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.
Which of the Dynamics products did you integrate with so far?