Payment Card Industry, Data Security Standard (PCI DSS) are a set of security standards for merchants who accept credit cards, both online and offline. They are not a governmental regulation or law, but rather guidelines for keeping your customer's payment card data secure developed by the PCI Security Standards Council. Enforcement of PCI compliance for merchants, as well as any penalties for non-compliance, is managed by the individual payment companies.
To achieve PCI DSS compliance, you need to follow the 12 requirements in the standard, working with your acquiring bank and the card brands you do business with. PCI compliance is an ongoing process of adhering to security policies, procedures, software design, network architecture and other security measures designed to make sure your customer's data is being kept secure.
Salesforce first achieved PCI DSS certification at Compliance Level 1 in November 2011. Salesforce's PCI Attestation of Compliance (AOC) document, which is updated yearly, can be requested from your Salesforce Account Executive if needed for a PCI audit.
Salesforce's PCI certification as a data storage service provider means that much of the PCI scope for Salesforce customers has already been dealt with. Since AppFrontier and the Chargent Payment Processing application never store data outside of Salesforce, Salesforce's PCI certification covers your data while it is at rest in the Salesforce database.
Salesforce customers who must adhere to PCI compliance may store Cardholder Data in Salesforce: Primary Account Number ("PAN" or "credit card number" or "Bank Account Number"), Cardholder Name, and Expiration Date, provided that they are stored using the proper security as detailed below in the Chargent PCI Implementation Guide.
Here are the 12 requirement areas for achieving PCI compliance. As you can see, usage of Salesforce to host your data and taking advantage of Salesforce-provided security features already get you a good part of the way toward PCI certification:
Build and Maintain a Secure Network and Systems
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Protect Cardholder Data
Requirement 3: Protect stored cardholder data
Requirement 4: Encrypt transmission of cardholder data across open, public networks
Maintain a Vulnerability Management Program
Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs
Requirement 6: Develop and maintain secure systems and applications
Implement Strong Access Control Measures
Requirement 7: Restrict access to cardholder data by business need to know
Requirement 8: Identify and authenticate access to system components
Requirement 9: Restrict physical access to cardholder data
Regularly Monitor and Test Networks
Requirement 10: Track and monitor all access to network resources and cardholder data
Requirement 11: Regularly test security systems and processes
Maintain an Information Security Policy
Requirement 12: Maintain a policy that addresses information security for all personnel.
Use of Salesforce or the Chargent Payment Processing for Salesforce add-on application does not transfer PCI compliance to your company. Your organization may need to achieve and maintain its own PCI compliance depending on your use cases.
While the appropriate use of Salesforce and Chargent are a key foundation for achieving PCI compliance, ultimately your organization is responsible for all other security processes and handling of credit card data that you collect.
Salesforce already handles much of your PCI Compliance scope with its advanced security features, but Chargent includes a number of capabilities to further reduce PCI scope. For a demonstration of any of these features, please Contact Us.
For PCI Compliance, Primary Account Numbers (PANs) may only be stored in Encrypted Custom Fields (ECFs) in Salesforce. PANs should not be stored in clear text fields, attached files, or any other location.
Encrypted custom fields are Salesforce text fields that can contain any letters, numbers or symbols but are encrypted. Examples of encrypted custom fields in the Chargent Payment Processing for Salesforce application include Expiration Month, Expiration Year, Bank Account Number, Credit Card Number, plus Merchant ID and Merchant Security Key in the gateway configuration.
Salesforce users see the data in Encrypted fields as a series of asterisks, but they can still edit or delete the data stored in those fields. For identification purposes, the last 4 digits of the credit card number field are shown in plain text.
Making encrypted fields visible in plain text by granting Salesforce user profiles the "View Encrypted Data" permission is not recommended. If you need to have certain user profiles that can view the encrypted fields in clear text rather than masked with asterisks, either on a permanent or temporarily enabled basis, you should have a clear written policy regarding how and why this is done.
Encrypted Field Implementation
Salesforce Profiles and Encrypted Custom Fields
Working with Encrypted Fields
If you store any of the following payment data in Salesforce, even in an Encrypted Field, your use of Salesforce will be non-compliant with PCI.
Some customers may wish to use the 3 or 4 digit security code (CVV2, etc.) for initial transactions. In that case, we recommend that you configure your payment gateway to not require the security code in order to approve transactions. Create a process, either manual or using the Chargent gateway field provided for this purpose, to remove the card security code so you do not store this after you run the first charge.
Each Chargent Payment Gateway record includes a field called Credit Card Handling. This field allows you to choose if/how credit card data is stored in different scenarios. For PCI Compliance or liability reasons, many customers do not wish to store credit card data. The options are as follows:
New in Chargent Base 2.19 is the "Clear CVV or Card Security Code" field. Simply add this field on any Gateway page layout, and by setting it to true (checking the box), the Card Security Code / CVV will automatically be deleted from its field on the Opportunity, Case, or Chargent Orders object as soon as the first approved transaction goes through. We recommend enabling this feature to facilitate your PCI compliance efforts.
The Chargent Gateway object should generally only be available to the administrator of your Salesforce account or a finance person. During normal operation of Chargent Payment Processing for Salesforce, you should give read-only permissions to the Gateway object and associated tab, fields, etc. to any Salesforce users who would not normally have access to your payment accounts.
Create, Edit and Delete permissions on the Gateway should be given only to System Administrators and/or finance profiles. You can remove the Gateway field from page layouts if you only have one active gateway, since in that case the single active gateway will automatically be chosen for any transactions.
Chargent Payment Processing for Salesforce’s Payment Console feature allows you to submit payments directly from a Salesforce modal (popup) window to your payment gateway. In addition to being a customizable, convenient interface for call center agents, customer service, billing or sales teams, it is able to initiate payments, receive tokens back from the payment gateway, and create transaction records in Salesforce.
Most importantly, with the Payment Console feature, transactions and tokens are created without ever saving or storing cardholder account number information in Salesforce.
Please note that the Chargent Payment Console feature requires a Chargent Platform edition license. Please contact us for details.
Another security feature to consider using is tokenization. Tokenization lowers your liability and the scope of a PCI audit, as you won't be storing account numbers in Salesforce. The downside of tokenization is that you lose some control over your data, as tokens are unique to the payment gateway provider, and cannot be moved between payment providers.
Tokenization is not a Salesforce security feature, but is a payment gateway technology supported by Chargent in many of our payment gateway integrations. Your payment gateway / processor will store the credit card data for you, and give you back a unique token which you then store in Salesforce to use for any future transactions against that credit card.
Tokenization provides an additional level of security, since the token or surrogate value represents an account number that is now stored encrypted in an external system, rather than stored encrypted in your Salesforce org. In addition to reducing PCI compliance scope, tokenization helps satisfy a number of PCI requirements -- the mandate to store payment data in the minimum number of locations, as well as the requirement that access keys be stored securely in as few places as possible.
In credit card tokenization, the last 4 digits of the credit card are preserved for identification purposes. So your staff will still be able to identify the correct card to a customer with the token stored in Salesforce, no differently than with the encrypted credit card number field, which shows asterisks except for the last 4 digits.
Salesforce is designed to be highly secure, but also to deliver flexibility for you to implement your own security design to meet the needs of your organization. Salesforce therefore has a large number of security features that Salesforce System Administrators need to configure to support their organization's PCI controls. Here are several of the more common ones, but for complete details we recommend reviewing Salesforce's security documentation directly, especially the Security Implementation Guide.
Salesforce gives you a number of capabilities to control the security of your users passwords, such as the level of complexity required for your passwords, and specifying an amount of time before users' passwords expire. Salesforce's default security already addresses a portion PCI compliance requirement 2, since there are no default passwords. Initial passwords are always uniquely generated and there are default minimums for password length and character requirements.
Choosing which data in Salesforce your users or groups / types of users have access to is one of the most important aspects of data security. Salesforce delivers more in this area than perhaps any other system of its kind, with a layered approach to security where you have a large amount of flexibility and the ability to control data access on a very granular level. There are 3 basic areas that control data access in Salesforce:
Object Level Security (User Licenses and Profiles)
For the Chargent Payment Processing for Salesforce application, you must first assign a Chargent license to each user, in order for them to be able to see the Chargent fields and transaction records. System Administrators can control this by finding the Chargent Transaction package under Setup > Installed Packages and clicking the "Modify" link.
After that, Profiles are probably the most important aspect of controlling the security around Chargent's fields and any access to the Encrypted Fields. Each user is assigned a profile, which is typically related to their job function (eg. System Administrator, Sales, Billing, etc.). The profile can prevent a user from seeing, modifying, creating or deleting any record of a particular type of object (such as Opportunities, Transactions, or Chargent Orders).
In addition to profiles, Permission Sets are useful in granting additional access settings to particular users beyond the profile, because multiple permission sets can be granted to a single user, but each user can have only one profile.
Field-Level Security lets you protect certain fields on an object, without hiding the whole object from users. It is an important security feature of Salesforce, because even though you can use Page Layouts to hide certain fields from users based on their Profile, the fields will still be accessible in list views, reports, search and elsewhere if the user has permissions on the object that the field is part of. Field-Level Security can ensure that certain sensitive fields are completely protected from being viewed, edited, modified or deleted by users who you do not wish to have access to them.
Salesforce offers a variety of ways you can control who has what level of access to which records, including Organization-Wide sharing settings, role hierarchy, and Sharing Rules. Record-level Security in Salesforce tends to be more about separating data access for different business units or levels in an organization, and less about securely configuring Chargent Payment Processing for Salesforce and ensuring PCI compliance, so please refer to Salesforce's security documentation to learn more.
AppFrontier recommends enabling field history on a number of Chargent fields, to provide an audit trail of what values have been changed in those key fields, and by whom. You may also wish to enable field history on certain fields in other objects such as Accounts and Contacts.
When Field History is enabled on a particular field, modifying that field adds an entry to the History related list on that object. All history entries include the time, date, what was changed, and which Salesforce user made the change. Note that up to 20 fields per object can be tracked, and some types of fields such as formulas and roll-up summaries cannot have history tracking enabled.
The Chargent fields which we recommend turning on history tracking are as follows:
Opportunity / Case / Chargent Order Custom Fields
Billing Zip Code/Post Code
Card Expiration Month
Card Expiration Year
Card Security Code
For ACH / eCheck transactions:
Bank Account Name
Bank Account Number
Bank Account Type
Bank Routing Nmber
Specific to the Chargent Orders (custom object):
Total (replaces the Amount field)
Transactions (custom object):
Many of the fields above, with a few additions:
To track field history for the Chargent custom objects:
To set up field history tracking on standard objects such as Opportunities and Cases:
PCI DSS Self-Assessment Questionnaire (SAQ)
(Many merchants and service providers can self-evaluate compliance with PCI using the SAQ. Please consult your acquiring bank for details regarding your particular PCI DSS validation requirements.)
Payment Card Industry (PCI) Data Security Standard
Requirements and Security Assessment Procedures, Version 3.0, November 2013