PCI Certification Overview #
The Payment Card Industry Data Security Standard (PCI DSS) is a set of security standards for merchants who accept credit cards, both online and offline. They are not governmental regulations or laws 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 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 and PCI #
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.
As a data storage service provider, Salesforce’s PCI certification means that much of the PCI scope for Salesforce customers is already covered. Since AppFrontier and the Chargent 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, such as 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.
As you can see, using 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.
The 12 Requirement Areas for Achieving PCI Compliance
Build and Maintain a Secure Network and Systems
- Install and maintain a firewall configuration to protect cardholder data
- Do not use vendor-supplied defaults for system passwords and other security parameters
Protect Cardholder Data
- Protect stored cardholder data
- Encrypt transmission of cardholder data across open, public networks
Maintain a Vulnerability Management Program
- Protect all systems against malware and regularly update anti-virus software or programs
- Develop and maintain secure systems and applications
Implement Strong Access Control Measures
- Restrict access to cardholder data by business need to know
- Identify and authenticate access to system components
- Restrict physical access to cardholder data
Regularly Monitor and Test Networks
- Track and monitor all access to network resources and cardholder data
- Regularly test security systems and processes
Maintain an Information Security Policy
- Maintain a policy that addresses information security for all personnel.
Your Organization’s PCI Compliance #
Use of Salesforce or the Chargent Payment Processing for Salesforce add-on application does not make you PCI compliant. 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 is 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.
Chargent PCI Implementation Guide #
Salesforce already handles much of your PCI Compliance scope with its advanced security features, but Chargent includes a number of capabilities to reduce PCI scope further. For a demonstration of any of these features, please Contact Us.
Encrypted Custom Fields
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 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
- Encrypted fields are encrypted with 128-bit master keys and use the AES (Advanced Encryption Standard) algorithm. You can archive, delete, and import your master encryption key. To enable master encryption key management, contact salesforce.com.
- You can use encrypted fields in email templates, but the value is always masked regardless of whether your Salesforce user profile has the “View Encrypted Data” permission.
- Ensure your organization has secure connections using SSL (Secure Sockets Layer) enabled.
- Only the <apex:outputField> component supports presenting encrypted fields in Visualforce pages.
Salesforce Profiles and Encrypted Custom Fields
- User profiles who have the “View Encrypted Data” configuration enabled will be able to view the field normally (in plain text).
- Users who do not have the “View Encrypted Data” profile will see the mask (asterisks), even if they have the “Modify All Data” permission.
- The “View Encrypted Data” permission can only be enabled on custom profiles. The standard System Administrator profile cannot be given “View Encrypted Data” permissions without being cloned first to create a custom profile.
- If you have the “View Encrypted Data” permission and grant login access to another user, be aware that the other user can see encrypted fields unmasked (in plain text).
Working with Encrypted Fields
- If a user clones a record with encrypted custom fields, Salesforce will only copy the data from the encrypted fields if the user has the “view encrypted data” permission. So generally, cloning records such as Opportunities or Chargent Orders will not copy the data in the encrypted fields.
- Encrypted fields are editable regardless of whether the user has the “View Encrypted Data” permission. So Salesforce users who see asterisks instead of clear text in encrypted fields can still change, update or delete the values. Use validation rules, field-level security settings, or page layout settings to prevent users from editing encrypted fields.
- You can still validate the values of encrypted fields using validation rules or Apex. Both work regardless of whether the user has the “View Encrypted Data” permission. Data for encrypted fields in the debug log is masked.
Data that should NOT be stored in Salesforce #
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.
- full magnetic stripe/chip
- PINs/PIN blocks
- CAV2/CVC2/CVV/CID (3 or 4-digit card security code)
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 not to 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.
Credit Card Handling Field
Each Chargent Payment Gateway record includes a field called Credit Card Handling. This field lets you 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:
- Never Clear: Chargent will not remove any card data automatically.
- Clear After Successful Charge: Chargent will clear the credit card number, expiration dates, and card security code only after a successful charge is run.
- Clear After All Transactions: The credit card number, expiration date, and card security code will be erased after any transaction (Charge, Void, Refund)
- Clear When Token Present: Only when a token is present in the token field will the credit card number, expiration date, and card security code be cleared.
Clear CVV / Card Security Code Field
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.
Chargent Gateway Object #
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 Console #
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.
Tokenization #
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 losing 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 for 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 and 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.
Other Salesforce Security Features #
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 many 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.
Password Rules
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 of PCI compliance requirement 2 since there are no default passwords. Initial passwords are always uniquely generated, with default minimums for password length and character requirements.
Sharing Model
Choosing which data in Salesforce your users or groups/types of users can access 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:
- Permission Sets and Profiles control the objects and features that users can access
- Field-Level Security and profile page layouts control the fields that users can access
- Organization-Wide sharing settings, role hierarchy, and sharing rules all control the individual records that users can access
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 object type (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
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.
Record-Level Security
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.
Field History Tracking #
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 that we recommend turning on history tracking are as follows:
Chargent Order Custom Fields
- Amount
- Billing Address
- Billing Zip Code/Post Code
- Billing Email
- Card Expiration Month
- Card Expiration Year
- Card Number
- Card Security Code
- Charge Amount
- Manual Charge
- Payment Method
- Subtotal
- Tax
- Shipping
- Total (replaces the Amount field)
For ACH / eCheck transactions:
- Account Name
- Bank Account Name
- Bank Account Number
- Bank Account Type
- Bank Routing Number
- Bank Name
Transactions (custom object):
Many of the fields above, with a few additions:
- Recurring
- Gateway ID
- Type
For setup instructions, visit Field History Tracking.
Additional Resources #
- PCI Security Standards Council
- 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, v4.0, December 2022
- Salesforce Security Implementation Guide
- Salesforce Security, Privacy, and Architecture Documentation
- The Developers Guide to PCI-Compliant Web applications
- Six Ways to Reduce PCI DSS Audit Scope by Tokenizing Cardholder Data
