Security and Privacy Guidelines for Merchants

Visa Click to Pay

For Merchants and Payment Service Providers


Start a Project
API Overview
API Reference

Security and Privacy Guidelines

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

Security

API Invocations

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

Client Authentication

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:

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

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

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

Transport Security

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.

Message Security

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:

The approved Asymmetric Encryption algorithms are:

The approved hashing algorithms are:

Cross-Origin Resource Sharing (CORS) Restriction

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.

Front End API Invocations

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

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:

Clickjacking Mitigation

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:

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:

Crossframe Scripting Mitigation (XFS)

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;}.

Post Message Security Considerations

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)

Step 1 Example

Step 4 Example

HTTP Strict Transport Security (HSTS)

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:

Content Security Policy (CSP) Directives

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.

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