This section describes security and data usage and retention policies for Visa Click to Pay integration.

The following sections define Visa-recommended approaches to secure communications between Digital Terminals and the Visa Click to Pay system.

All clients must have a Visa Developer Portal account. Once registered, the requestor will receive access credentials, which allows the use of Visa Digital Commerce Program APIs. These credentials consist of an API key and a shared secret, which must never be shared beyond trusted individuals and services.

Visa Developer Portal credentials include:

• Visa Client ID
• API Key with agreed upon Signature/Encryption scheme. The options that Visa Click to Pay currently supports are:
  • Shared secret
  • Mutual TLS (for client authentication)

Note: Authentication credentials are different for the testing and production environments.

All Digital Terminals must authenticate with Visa using the following methods:

• Authentication credentials passed in the HTTPS basic authorization header.
• SSL/TLS X.509 Visa-approved client certificate linked to the identity supplied in the authorization header (optional).

Note: Only x-pay-token (using shared secret) or mutual TLS can be used as authentication options for backend-to-backend interactions for clients.

All messages to Visa must be sent through an approved transport channel with the required authentication and authorization scheme for the type and format of the information which is passed.

All DPA must use SSL/TLS for exchanging messages with Visa. Not all TLS versions are currently supported. The approved version of TLS is 1.2 or higher.

• All PCI/PII information contained in the messages to Visa must be encrypted.
• The DPA should be PCI-compliant to secure its systems and the PCI data contained therein against unauthorized access, use, or disclosure.
• PCI data in transit should be masked or encrypted (when shared in full).
  
• PII data should be hashed, masked, or encrypted.

The approved symmetric encryption algorithm is Advanced Encryption Standard (AES). AES usage must have a minimum key size of 256 bits. AES based encryption must be done using one of the following modes:

• CCM
• CTR
• CBC
• XTS
• AES-GCM mode can be used as a stand-alone MAC to authenticate messages when there is no data to encrypt
• AES-GCM when used must have an Initialization Vector (IV) or 96 bits or more.

The approved Asymmetric Encryption algorithms are:

• Elliptic Curve Cryptography (ECC)
• Rivest-Shamir-Adelman (RSA)

The approved hashing algorithms are:

• SHA-2 including the cryptographic hash functions (SHA-224, SHA-256, SHA-384, and SHA-512)
• Keccak-SHA-3a

Cross-Origin Resource Sharing (CORS) uses additional HTTP headers to enable a web application from one origin (domain, protocol, and port) to access selected resources from a server in a different origin. A web application executes a cross-origin HTTP request for a resource from a different origin than its own. iFrame should not use document.domain and CORS in Ajax should be disabled.

The following guidelines can be used as a starting point when designing a solution to secure the DPA front end for Click to Pay checkout.

Sanitization helps to defend against XSS attacks in the front-end JS code. Before inserting any external data into the DOM (when data is passed between DPA FE and the Click to Pay SDK), the DPA should convert any characters contained therein that could be used to transform an innocent string into an offending piece of HTML/JavaScript code:

• Convert < into &lt;
• Convert > into &gt;
• Convert & into &amp;
• Convert " into &quot;
• Convert ' into &#39;

Visa recommends that a DPA use iFrames for loading the front-end code for DPA FE, Click to Pay system FE, and DCF FE. (Pop-up is an additional method for displaying the front-end component, depending on browser support). Reasons include:

• Isolation
• Does not block rendering
• Not blocked by main page JS rendering
• Ease of update/versioning

Web pages that are rendered in iFrames or pop-ups, such as the Click to Pay system FE, are vulnerable to clickjacking attacks. DPA can use an X-Frame-Options header wherever the ALLOW-FROM option is supported (e.g., Firefox, IE). In this case, use sandbox attributes for iFrames and only allow selective capabilities.

A DPA cannot use X-Frame-Options for browsers that do not support ALLOW-FROM (e.g., Chrome, Safari). Therefore, for all actions that modify the data, the best mitigation against clickjacking for unsupported browsers is to always display confirmation for all actions in a way that cannot be impersonated via clickjacking.

X-Frame-Options:

• X-XSS-Protection helps protect against XSS and iFrame based clickjacking attacks.

Frame Busting is a term for JavaScript code used to combat XFS attacks. Integration of this solution prevents the use of websites as malicious iFrame traps.

The most common Frame Busting code is made up of two basic elements: a conditional statement and a counter action. For more details, see: https://www.checkmarx.com/knowledge/knowledgebase/XFS.

Example:       if (top != self) {top.location = self.location;}.

The postMessage specification recommends the following steps to ensure the safety of the process when using cross-document messaging:

1. Check the origin attribute to ensure that messages are only accepted from domains from which you expect to receive messages. (See Step 1 Example)
2. If you do not check the origin attribute and instead accept messages from any origin, keep in mind the potential risk for denial-of-service attacks. Controlling the number of messages accepted per minute could offer protection in this case.
   
3. Check the data received to be sure it is the type of data you are expecting.
4. Specify the target origin when sending messages. (See Step 4 Example)

Once a supported browser receives this header, the browser will prevent any communications from being sent over HTTP to the specified domain and will instead send all communications over HTTPS. This also prevents HTTPS click-through prompts on browsers.

Example:       “Strict-Transport-Security: max-age=31536000; includeSubDomains”.

HTTP API response must include following headers with appropriate values:

• HTTP Strict Transport Security (HSTS)
• X-Frame-Options
• X-XSS-Protection
• X-Content-Type-Options

Always enforce Strict-Transport-Security using CSP. A primary goal of CSP is to mitigate and report XSS attacks. In addition to restricting the domains from which content can be loaded, the server can specify which protocols are allowed to be used; for example (and ideally, from a security standpoint), a server can specify that all content must be loaded using HTTPS.

• Content Security Policy (CSP) is an added layer of security that helps detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks.
• Implement Content Security Policy Level 3 in blocking mode: This requirement is not a replacement for careful input validation and output encoding, intended as a first additional line of defense.

Configure the web server to return the Content-Security-Policy HTTP header. The policy must include:

• A default-src or script-src directive to prevent inline scripts from running, as well as blocking the use of eval().
• A default-src or style-src directive to restrict inline styles from being applied from a <style> element or a style attribute.
• Specifying require-sri-for directive that instructs the client to require the use of Subresource Integrity for scripts or styles on the page.
• Using frame-ancestors CSP Directive to specify valid parents that may embed a page using iFrames.

The following masking rules are followed when applicable in an API:

• Plaintext exposure cannot exceed 3 characters or 30% of the total PI field length, whichever is shorter.
• Masking of the remaining 70% can either be the first 70% of the PI field, the last 70% of the PI field, or a random 70% of the field.
• Use the special character * to mask characters being presented to enforce consistency in masking logic.
• If the PI field is email address, the domain name should be left clear.

Cryptographic material includes, but is not limited to, the keys below

“Personal Information” or “PI” data means any information relating to an identified or identifiable natural person (“Data Subject”), or any information that is combined with such individually identifiable information, including information that can be used to authenticate that individual or access an account. This definition also includes, but is not limited to, “Cardholder Information”.

“Cardholder Information” means (i) with respect to a payment card, the account holder’s name, Primary Account Number (“PAN”) or any other number that is mapped to or a surrogate for a PAN, service code, card validation code/value, PIN or PIN block, valid to and from dates and magnetic stripe data; (ii) any information sufficient to enable an alternate form factor to use an underlying payment card account to initiate a payment or other transaction; (iii) any information relating to a payment card transaction that is identifiable with a specific account. 

“Visa Data” means any information owned and provided by Visa, in any form, format or media (including paper, electronic and other records) that the Company has access to, obtains, uses, maintains, or otherwise handles in connection with the Program. Visa Data may include Visa PI and Cardholder Information.

Click to Pay System shares data with other Click to Pay participants only as reasonably needed to provide the Click to Pay services. DPA as well as all other players in VDCP, are responsible for handling and protecting Visa Data per requirements. Data handling requirements for high-level data elements are described in table below.