Credit card numbers hidden in MS Dynamics GP 10 after sp5 update

Question Status

Suggested Answer
bugman asked a question on 5 Jan 2011 9:23 AM

Just applied the 2010 Year End Payroll Tax Update to MS Dynamics 10.0, which included sp5 for Dynamics.  (Running on SBS2003, SQL 2005).

After installing, now customers' credit card numbers are masked/hidden in some windows, including (but not limited to) the Sales Payment Entry window.  It used to show all 16 digits of customer credit card number, now it only shows the last 4 - the first 12 are masked out with "X"'s.  This is a real pain as our sales agents need to see the credit card number while processing the invoice to punch the number into our crdit card processing machines to confirm payment before we can complete the invoice & approve the order.

Is there some new security setting perhaps that will revert back to the previous behavior of showing the entire credit card number in these windows?

Reply
Suggested Answer
Korey Lind responded on 8 Jan 2011 5:34 AM

In order to be PCI compliant, the credit card number needs to be encripted.  The encription is causing the first 12 digits to be displayed with X's.  If you were to undergo a PCI audit and had unencripted credit card information stored on the customer record you would fail the audit.   You would also be exposing yourselft to extremely high fines if there are any problems and you aren't PCI compliant (ie $5,000 per transaction).

I would recommend investing in a credit card processing solution such as Nodus.  The streamlined process (ie not having your sales people waste time going to the cc machine) and reduced processing fees due to using a PCI certified solution will quickly cover the cost of the Nodus.

Reply
Daniel Moore responded on 14 Sep 2012 9:35 AM

Hello!

It looks like Korey answered your question correctly, to be compliant the encription in GP is required and working as designed. There is no setting to unmask the credit card number. However you could look into using Modifier with VBA to possible modify the window to do what you want.

Let me know if you have any questions.

Best regards,

Dan Moore

Customer Online Technical Community

-----------------------------------------------------------------------------------------

We hope you get value from our new forums platform! Tell us what you think:

social.microsoft.com/.../threads

------------------------------------------------------------------------------------------

This posting is provided "AS IS" with no warranties, and confers no rights

Reply
Leslie Vail responded on 14 Sep 2012 7:42 PM

Dan has the answer!

Using Modifier/VBA you can use the before user changed (or before changed) event to get the number and record it somewhere else, say into a new local field on the window that you save to the DUOS table.

Kind regards,

Leslie

Reply
Suggested Answer
Korey Lind responded on 15 Sep 2012 6:35 AM

If the credit card number is encrypted as it should be you not be able to use VBA to reveal the code.   Plus if you do capture the data and put it in another field before saving, you will be violating the PCI-compliance rules.  If you have an issue and it discovered that you were storing the data in an field that was not encrypted, you could be subject to fines that are as much as $5000 per transaction.

I am not sure that recommending an option to circumvent the PCI-compliance rules is in the best interest of this community.  

We have also seen situations where the merchant bank have added an additional $1,000 plus per month fees if a non-PCI compliant systems was being used.

Adding a credit card solution to Dynamics GP that is PCI compliant and lets them process the card from within GP will save them money and eliminate a lot of risk.   Yes,  it might cost some to buy and implement, but they will get an ROI in a short time with time savings etc.

Korey

Third Wave Business Systems

www.twbs.com

Reply
Leslie Vail responded on 15 Sep 2012 7:27 AM

Korey,

I did not 'recommend' anyone circumvent the PCI-compliance rules, I merely spoke of existing functionality of GP. If this is a vulnerability of the software, perhaps it should be addressed in SP 6. We should probably put it on the product suggestion board, but I'm betting they already know.

At any rate, to reveal a way to get around GP's security would be irresponsible, it's up to each client to decide how they will handle contingent liabilities.

I doubt all of our customers are striving for PCI compliance.

Kind regards,

Leslie

Reply
Suggested Answer
Korey Lind responded on 15 Sep 2012 7:43 AM

Storing the number in a different unencrypted field is a violation of the PCI compliance rules.  And therefore recommending this approach is a recommendation to violate the rules.   It doesn't matter that you are recommending using standard GP functionality.  

Meeting the PCI compliance rules can be difficult.  Many companies think that it too much of hassle and causes extra steps.  It is definitely their choice to not be compliant.  However, they need to understand the risks and costs associated with the not being compliant.  If they arent compliant and someone takes the list of credit card numbers, they can be fined $5000 for each stolen card number!   if 100 card numbers are stolen, it is a $500,000 fine.  

If someone is going to recommend circumventing the rules, then you should outline risks associated with that approach.  

Reply
DanMoore responded on 17 Sep 2012 10:46 AM

Hello!

As mentioned before, GP masks these numbers to be compliant. You can use VBA to create a  customization to help with what you need. But as other posts have mentioned, since GP masks these to be compliant creating something to unmask them may not be compliant obviously.

However VBA is an option and you may be able to create a customization of some sort that is both compliant and does what you want.

For assistance with creating a VBA customization that will both fit what they need and be compliant you would want to submit a support incident to have it routed to the correct team who can help with this. Otherwise this is working as designed:

To create a support incident request, go to CustomerSource > Support > Assisted Support > New Support Requests, or, you can use this link: mbs.microsoft.com/.../createincident.aspx.

Best regards,

Dan Moore

Customer Online Technical Community

-----------------------------------------------------------------------------------------

We hope you get value from our new forums platform! Tell us what you think:

social.microsoft.com/.../threads

------------------------------------------------------------------------------------------

This posting is provided "AS IS" with no warranties, and confers no rights

Reply
Suggested Answer
Korey Lind responded on 8 Jan 2011 5:34 AM

In order to be PCI compliant, the credit card number needs to be encripted.  The encription is causing the first 12 digits to be displayed with X's.  If you were to undergo a PCI audit and had unencripted credit card information stored on the customer record you would fail the audit.   You would also be exposing yourselft to extremely high fines if there are any problems and you aren't PCI compliant (ie $5,000 per transaction).

I would recommend investing in a credit card processing solution such as Nodus.  The streamlined process (ie not having your sales people waste time going to the cc machine) and reduced processing fees due to using a PCI certified solution will quickly cover the cost of the Nodus.

Reply
Suggested Answer
Korey Lind responded on 15 Sep 2012 6:35 AM

If the credit card number is encrypted as it should be you not be able to use VBA to reveal the code.   Plus if you do capture the data and put it in another field before saving, you will be violating the PCI-compliance rules.  If you have an issue and it discovered that you were storing the data in an field that was not encrypted, you could be subject to fines that are as much as $5000 per transaction.

I am not sure that recommending an option to circumvent the PCI-compliance rules is in the best interest of this community.  

We have also seen situations where the merchant bank have added an additional $1,000 plus per month fees if a non-PCI compliant systems was being used.

Adding a credit card solution to Dynamics GP that is PCI compliant and lets them process the card from within GP will save them money and eliminate a lot of risk.   Yes,  it might cost some to buy and implement, but they will get an ROI in a short time with time savings etc.

Korey

Third Wave Business Systems

www.twbs.com

Reply
Suggested Answer
Korey Lind responded on 15 Sep 2012 7:43 AM

Storing the number in a different unencrypted field is a violation of the PCI compliance rules.  And therefore recommending this approach is a recommendation to violate the rules.   It doesn't matter that you are recommending using standard GP functionality.  

Meeting the PCI compliance rules can be difficult.  Many companies think that it too much of hassle and causes extra steps.  It is definitely their choice to not be compliant.  However, they need to understand the risks and costs associated with the not being compliant.  If they arent compliant and someone takes the list of credit card numbers, they can be fined $5000 for each stolen card number!   if 100 card numbers are stolen, it is a $500,000 fine.  

If someone is going to recommend circumventing the rules, then you should outline risks associated with that approach.  

Reply