Express security

To achieve the highest level of PCI-DSS 4.0 compliance using Express, disable the creation of payment methods via direct API. After confirming any alternative methods of adding a payment method are not in use, enable the "iFrame or Spreedly Express only" option from the Environment settings page in the Spreedly application.

This prevents direct API submission of payment methods which is required to detect malicious attacks and, in general, enforce adherence to the PCI standard. The only way payment methods can be added to this environment is via the Express (iFrame) payment form.

PCI-DSS 4.0

Starting March 31, 2025, all merchants will be subject to new payment page requirements under the updated PCI standards. One key aspect of these new requirements is the emphasis on script security for protecting sensitive cardholder data and PII on client-side environments, particularly as applied to any third-party script merchants use on their payment pages.

Under PCI-DSS 4.0, script integrity on payment pages must be explicitly verified and managed. Scripts must be sourced from trusted providers like Spreedly, securely implemented, and must be necessary for functionality on the payment page. The standard introduces requirements such as script monitoring, the need for a Content Security Policy, or sub-resource integrity to certify that scripts loaded on the page are not tampered with. Merchants must also include written justification as to why each script is necessary as part of their payment page script inventory.

Content Security Policy

Content Security Policy (CSP) adds a layer of security to your payment page, aimed at mitigating attacks like Cross-Site Scripting (XSS). By specifying trusted domains for the browser, CSP restricts the executable script sources and reduces vectors where XSS can occur. For iFrame, include https://*.spreedly.com/ as a valid domain to ensure proper loading of the Express assets. A well-configured CSP may help assist with restrictions on unauthorized or malicious scripts from being loaded and executed.

Script integrity

Merchants must verify and maintain script integrity for any third-party asset running on their payment page. This can be done using a combination of techniques and includes a number of varying mechanisms. Key examples are sub-resource integrity (SRI), file-integrity monitoring (FIM), manual review and whitelisting, or leveraging of other third-party providers to inspect their inventory, notifying and potentially blocking requests to any unauthorized or altered scripts running on the page.

This requirement applies to all third-party scripts on a payment page, including Spreedly Express. To that end, Spreedly will implement such an integrity mechanism which enables merchants to comply with this requirement.

Note: Spreedly will introduce this mechanism ahead of the merchant deadline. This will be complete with updated documentation including script integrity information, and instructions for implementation and maintenance of the Express payment form. There will be updates to our deprecation policy to ensure merchants are able to leverage this mechanism on recent, supported versions of the script.

Script inventory

Another aspect of PCI-DSS 4.0 is the requirement for merchants to keep an inventory of all third-party scripts on their payment page, along with the justification for usage as part of the page's functionality.

For Express, an example justification could relate to the need for secure tokenization of cardholder data, including PAN and CVV, as part of the overall payment flow.