- 05 Jul 2023
- 6 Minutes to read
- Print
- DarkLight
- PDF
How to Securely Implement ChargeLogic
- Updated on 05 Jul 2023
- 6 Minutes to read
- Print
- DarkLight
- PDF
Overview
ChargeLogic Payments is a PA-DSS validated payment application, which, when implemented in accordance with this document and in a secure environment, will not prevent the merchant from being PCI compliant. Compliance guidelines can be found at https://www.pcisecuritystandards.org.
However, there is more to a secure implementation than simply using a validated payment application. You must be aware of how the payment application interacts with its overall environment and how the payment application uses and protects cardholder data. This document provides guidance on the requirements you should consider for a secure implementation on the SaaS Microsoft Dynamics 365 Business Central product.
On-premise and/or Perpetual deployments require the participation of a Microsoft partner; further documentation for secure implementation for non-SaaS deployments is available for ChargeLogic’s Microsoft partners on the ChargeLogic Partner Portal. Please contact us for access to the ChargeLogic Partner Portal.
Hardware and Operating System Requirements
ChargeLogic Payments version 4.0.xx supports Microsoft Dynamics 365 Business Central, both hosted and on-premise deployments, and it supports the operating system and hardware environments that Dynamics 365 Business Central supports.
To determine the ChargeLogic Payments version, navigate to Extension Management on your Business Central Instance.
Cloud deployments of Dynamics 365 Business Central require one of the below browsers:
Microsoft Edge (latest publicly available version) on Windows 10.
Internet Explorer 11 on Windows 10, Windows 8.1, or Windows 7.
Google Chrome (latest publicly available version).
Apple Safari (latest publicly available version).
Card Present Environments
If you take credit card payments with the customer present, then ChargeLogic requires usage of one of the following semi-integrated solutions:
Use of the Datacap TranCloud service and supported PIN pad devices, or
Use of the CardConnect portal service and supported PIN pad devices.
These semi-integrated solutions also comply with PCI standards. Datacap uses a combination of its PA-DSS validated payment application and any processor-level encryption or Point to Point Encryption (P2PE) hardware solutions available.
CardConnect leverages its PCI compliant gateway as well as its own tokenization and P2PE hardware solution.
Setup Wizard
Use of the ChargeLogic Setup Wizard (https://www.chargelogic.com/support/chargelogic-payments-setup-wizard/) will securely deploy ChargeLogic Payments according to the requirements of PA-DSS. Any custom changes to the secure deployment give the potential to invalidate the out of the box deployment.
The Setup Wizard will set up a production (live) and sandbox environment. Your sandbox database should never store actual customer credit card data.
Permissions
At the end of the Setup Wizard, add the ChargeLogic Payments Permission Sets to the appropriate User Groups. It is very important that users only have access to the cardholder data required to fulfill the duties of their job. Access to sensitive data should be logged and you should not allow “Super User” status by default.
EFT-SETUP should be given to users who will administer the system. Please be advised that the EFT-SETUP Permission Set gives access to read and write the Encryption Key used to secure cardholder information (see Data Protection – Encryption below). ChargeLogic recommends that access to the EFT Setup table in the database, key file location, and cryptographic keys be restricted to the fewest number of key custodians necessary and that cryptographic keys neither be copied nor distributed outside of the ChargeLogic Payments environment at any time. ChargeLogic recommends that assigned key custodians sign a form specifying that they understand and accept their responsibilities as key custodian prior to access being granted. Implementers and customer key custodians must store keys securely in the fewest possible locations and forms.
Permission Sets can be assigned under EFT Setup→General Tab→Permission Sets. However, this table should be left blank unless you are explicitly trying to limit access for specified groups.
Data Protection – Tokenization
Most Business Central deployments will make use of tokenization as the default data protection type. When using tokenization, the processor provides a token for the merchant to store instead of the actual cardholder data. These tokens cannot be used by anyone who steals them from the system. Usage of tokenization can drastically reduce the scope of a PCI audit because cardholder data are not being stored, but there is the possibility of cardholder data passing through the system during the acquisition of the token. Usage of a SRED hardware device available with the CardConnect service can remove the possibility of cardholder data passing through the system prior to getting a token.
Data Protection – Encryption
ChargeLogic Payments also allows the cardholder data to be stored encrypted in the NAV database, if tokenization is not being used. Encrypted storage is PCI compliant, but it puts a greater liability onto the merchant and/or software hosting service to maintain the security of the storage database. Business Central deployments that are hosted on Microsoft’s cloud on Azure rely on Microsoft Azure’s annual PCI audit (https://www.microsoft.com/en-us/trustcenter/compliance/pci).
If encrypted storage is being used, cardholder data could be stored in any of the following tables:
Table Name | Table Number |
---|---|
Sales Header | 36 |
General Journal Line | 81 |
Sales Invoice Header | 112 |
Sales Credit Memo Header | 114 |
Service Header | 5900 |
Service Invoice Header | 5992 |
Service Credit Memo Header | 5994 |
EFT Transaction | 37028310 |
Customer Credit Card | 37028311 |
EFT Transaction Archive | 37028357 |
Customer Checking Account | 37028452 |
ChargeLogic does not retain prohibited sensitive data, such as PINs, magnetic stripe contents, or security codes. They are used to process transactions, then they are forgotten by the system.
If you are using Encrypted Storage instead of tokenization, ChargeLogic will be using a Data Encrypting Key (DEK) for cardholder data protection. The ChargeLogic Payments cryptographic interface allows for the dynamic generation up to one strong 192-bit cryptographic key. The DEK displayed on the EFT Setup is encrypted by the Key Encrypting Key (KEK). KEKs and DEKs are managed programmatically by the ChargeLogic Payments program and are thus unknown to key custodians.
If you are using Encrypted Storage instead of tokenization, PCI requirements mandate that you rotate your Encryption key at least once per year and in the case of known or suspected compromised encryption keys. The system will remind you by generating a message based on a value in the EFT Setup record on the General Fast tab named “Data Enc. Key Validity Period,” which by default is set to 1Y. Plan to do this off-hours because the process can take a long period of time if there are a large number of transactions and other records (Sales Headers, Posted Sales Invoices, Customer Credit Cards, etc.).
To reset the encryption key, go EFT Setup→Actions tab→Functions→Reset Encryption Key.
The Reset Encryption Key function will re-encrypt the credit card information in the system for stored credit cards and credit card transactions, adding additional credit card security to your system. As required for PCI compliance, retired cryptographic keys will be rendered irretrievable.
ChargeLogic recommends that all end customers establish and maintain a best practice-based Key Management Procedures for internal use. Please reference the National Institute of Standards and Technology (NIST) Special Publication 800-57 for further information and reference (https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-4/final).
Data Visibility
No matter the Data Protection Type, ChargeLogic Payments does not display the entire Protected Account Number (PAN) on the screen. The PAN is masked, with only the last four digits shown, just as you would see on a printed receipt. In the case of tokenization, the full cardholder data is not actually present in that field. It is possible to view the first six digits of the card in the table data, which identify the card issuer. Access to this data is also PCI-compliant.
Data Deletion and Purging
There are a few ways available to manage/delete cardholder data in the system.
Data Deletion
Stored Customer Credit Card and Customer Checking Account data can be deleted. Go to EFT Setup→Navigate Tab→General→Advanced→Data Deletion and select the Delete Customer Payment Data batch report.
Stored Account Numbers can be purged from the system. Go to EFT Setup→Navigate Tab→General→Advanced→Data Deletion and select the Cleanse Cardholder Data batch report.