- Strong Customer Authentication
- What is Strong Customer Authentication
- What Chargent Features Use SCA?
- Testing SCA
- PCI CERTIFICATION OVERVIEW
- Salesforce and PCI
- Your Organization's PCI Compliance
- Chargent PCI Implementation Guide
- Data that should not be stored in Salesforce
- Chargent Gateway Object
- Chargent Payment Console
- Other Salesforce Security Features
- Field History Tracking
- Additional Resources
Strong Customer Authentication #
What is Strong Customer Authentication #
The European Payment Services Directive (PSD2) aims to provide more secure credit card transactions, and protect cardholders from fraud, by adding an extra layer of security to customer initiated transactions (CIT). This is called Strong Customer Authentication (SCA).
SCA is a two-factor authentication requirement wherein, during a consumer initiated transaction (CIT), the cardholder must provide two of the three elements:
- Something the card holder knows (such as passwords, passphrases, PIN, sequences, and secret facts)
- Something the card owns (such as cellphones, smartwatches or other wearable devices, smart cards, tokens, and badges)
- Something the card Is (fingerprints, facial recognition, voice patterns, iris format, and DNA signatures)
SCA works with Customer Initiated Transactions (CIT) so when you use Chargents Payment Request Feature or Take Payments in Communities, the person entering the credit card will receive a pop-up asking them to authenticate in order to process the payment The SCA authentication is a process dictated by their issuing bank. For some banks, you will have to log in using your Username and Password, for others, the issuing bank may use a key generator to authenticate on your mobile device or computer.
SCA currently works with the Adyen Gateway. You will need to work with your Adyen to have SCA enabled on the gateway side.
- Adyen – Once enabled with Adyen, you won’t need to enable it within your Salesforce Gateway Record. SCA is built into the integration with Adyen and will detect EU merchants and EU Credit Cards automatically.
What Chargent Features Use SCA? #
Payment Requests: When you send a Payment Request, the customer will receive a link to a payform. When they enter in their credit card information they will receive a pop-up notification asking for authentication.
Take Payments Component in Communities: Take Payments Component is part of our Platform Edition. It allows you to add a payform within your community site. Your users can access their account information, allowing them to sign into your community portal and make their payment using your payform.
Testing SCA #
Each Gateway uses its own 3DS test credit card numbers to allow for testing before rolling it out. These are different from the test credit cards provided for standard testing. You should always test in Sandbox before rolling out to Production in order to make sure all customizations still work as expected in your Org.
Testing via Payment Request
To test using a Payment Request you want to be sure you have the Chargent Payment Request feature set up as outlined in our documentation.
- Click the [Send Payment Request] button
- If you have multiple Payment Request templates set up you will first choose what template you want to use.
- Enter an email address where you want to send the test Payment Request along with any amount.
- Enter a Contact name (Optional)
- Click the [Send Request] button
When you receive the email, click the secure link for the Payment Request. Use one of Adyen test credit cards to complete the payform and submit the payment.
When you click the [Pay] button, you will see a pop-up asking you to authenticate by entering in a password or whatever your issuing bank uses for verifying it’s you making the payment. This is the second layer of security using SCA.
Once you submit your authentication, you will receive a message stating ‘Your payment was submitted successfully’..
Adyen Test Credit Cards
|Card Type||Card Number||Expiry Date||Security Code|
|Visa||4917 6100 0000 0000||03/2030||737|
|Visa||4212 3456 7891 0006||03/2030||737|
|Mastercard||5212 3456 7890 1234||03/2030||737|
|American Express||3714 4963 5398 431||03/2030||7373|
|Discover||6011 1111 1111 1117||03/2030||737|
|Diners||3056 9309 0259 04||03/2030||737|
PCI CERTIFICATION OVERVIEW #
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 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.
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
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.
Your Organization’s PCI Compliance #
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.
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 further reduce PCI scope. 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 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
- 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.
- Make sure 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 to first create a custom profile.
- If you have the “View Encrypted Data” permission and you grant login access to another user, be aware that the other user will be able to see encrypted fields unmasked (in plain text).
Working with Encrypted Fields
- If a user clones a record that has 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 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.
Credit Card Handling Field
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:
- 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.
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.
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 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:
- 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 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.
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 which we recommend turning on history tracking are as follows:
Chargent Order Custom Fields
- 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 MethodSubtotal
- 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:
- Gateway ID
To track field history for the Chargent custom objects:
- Go to Setup > Create > Objects
- Click Edit next to the name of the custom object.
- Select the Track Field History checkbox.
- After enabling history tracking for an object, customize your page layouts to add the object’s history related list.
- Click Save
- Click Set History Tracking in the Custom Fields & Relationships section. This section allows you to set a custom object’s history for both standard and custom fields.
- Click Save. Salesforce will track history from this date and time forward. Changes made prior to activating tracking are not included.
To set up field history tracking on standard objects such as Opportunities and Cases:
- Go to Setup > Customize
- Select the object you want to set up.
- Click Fields > Set History Tracking.
- After enabling history tracking for an object, customize your page layouts to add the object’s history related list.
- For accounts, contacts, and opportunities, select the Enable Account History, Enable Contact History, or Enable Opportunity History checkbox.
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, Version 3.0, November 2013
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