Skip to main content

Security measures for Payment Pages 2.0

Zuora

Security measures for Payment Pages 2.0

Zuora's approach to securing hosted payment pages

Zuora uses a defense-in-depth security strategy for Payment Pages 2.0 (HPM 2.0). Through Zuora’s layered security features, you can tailor security controls based on your specific needs. Zuora is serious about security and works diligently to enhance our security and privacy programs to address new challenges. 

Securing your hosted payment pages is a shared responsibility between Zuora and your business. You must ensure that personal data and payment card information (PCI)  processed during a  transaction are protected against unauthorized access. In addition to implementing your own security program for your website and user accounts, it is strongly recommended that you implement the Payment Pages 2.0 security measures described in the following sections.

This article provides suggestions and guidance on the implementation of the following security measures:

  • Approaches to preventing card testing fraud
  • Your own necessary security infrastructure
  • Zuora’s out-of-box security measures, including:
    Security Measure Description
    IP-based rate limiting Limit the number of times a hosted payment page can be submitted from the same IP address within a time range.
    Card-based rate limiting Limit the times a hosted payment page can be submitted for the same card within a time range.
    Tenant-level submission rate limiting Limit the number of attempts to submit payment pages from the same tenant.
    Support for CAPTCHA challenges Detect and block requests originating from a bot, while allowing legitimate traffic to pass.
    HPM Smart Bot Attacking Prevention Google reCAPTCHA Enterprise Interactive Test (Checkbox) version can be dynamically enabled and configured when attacks are identified.
    Token expiration management When end-users hit the threshold by repeatedly submitting incorrect information on the hosted payment page, they will see the error message and will be blocked from all further hosted payment page submissions.
    Support for 3D Secure The Strong Customer Authentication regulation requires the use of 3D Secure for card payments in the United Kingdom and the European Economic Area. 3D Secure requires end users to complete an additional verification step when making a payment.
    Client-side Payment Page parameter validation When receiving a request for rendering or submitting a hosted payment page, the client parameters in the request are validated by comparing the value in the request with the value specified in the digital signature.
    Support for Address Verification Service Pass the address information entered by the end user to the gateway and compare it with the cardholder's billing address on record with the card issuer.
    Support for email address verification Pass the email address information entered by the end user to the gateway and compare it with the cardholder's email address on record with the card issuer.
    Zuora Fraud Protection Zuora integrates with Microsoft Dynamics 365 Fraud Protection to provide an opt-in payment fraud protection service.

Prevent card testing fraud

A card testing attack is when a malicious actor or group attempts to validate stolen card information. Fraudsters usually validate the card information with small payments or authorizations, which are less likely to be noticed by cardholders. These tactics are usually automated, so large numbers of cards can be tested with minimal human involvement. The negative consequences of card testing fraud include the following:

  • Additional transaction charges from payment gateways
  • Damage to a company’s reputation due to security issues and loss experienced by end customers
  • Revenue impact due to suspension or fines from merchant services
  • Potential disablement by the payment providers
  • Payment card fraud and chargebacks

There are some effective approaches to preventing card testing attacks. Here are some examples:

  • Increase the number of required matching security elements, such as address verification, CVV (Card Verification Value), expiration date, etc.
  • Implement security measures such as CAPTCHA challenges for bot attacks.
  • Deploy 3D Secure for additional authentication for regions that support it.
  • Limit checkout attempts.
  • Regularly monitor the transactions to identify card testing fraud.

Zuora has implemented multiple security features into Payment Pages 2.0 and provides continuous protection as new threats are developed. We recommend that you stay up to date with our latest Payment Pages 2.0 features. You can optimize your Payment Pages 2.0 integration by using Zuora’s out-of-box security measures to minimize your efforts in implementing some of your security approaches.

Protect your user accounts and website

This section provides suggestions on the implementation of your own necessary security infrastructure to protect your website and user accounts.

Protect login procedures with Multi-Factor Authentication

Multi-Factor Authentication (MFA) is a security measure to confirm identity to gain access to a user’s online account. It requires the user to provide two or more verification factors rather than just asking for a username and password before logging in to a user account. Some MFA options include but are not limited to the following:

  • Email
  • SMS
  • Physical token
  • Random pin
  • Biometrics such as fingerprint
  • Authenticator application

Zuora recommends that you implement MFA on your login pages.

Protect your website with Google reCAPTCHA Enterprise

Due to the increased sophistication of fraudsters and botnet owners, new tools have been developed to distinguish between bots and humans. This technology can detect and block requests originating from a bot, while allowing legitimate traffic to pass. One example of this technology is Google reCAPTCHA Enterprise. As described by Google, Google reCAPTCHA Enterprise provides comprehensive protection against bot-based online fraud attacks while enabling real web user interactions to proceed seamlessly.

We strongly recommend that you utilize your own Google reCAPTCHA license to maximize the effectiveness of the reCAPTCHA algorithm on your web pages. As a part of Zuora’s constant effort to protect the security of Zuora’s hosted payment pages, Zuora recommends that you install Google reCAPTCHA Enterprise.  

Data privacy and security in Google reCAPTCHA

Google reCAPTCHA will collect hardware and software information, such as device and application data, and send the data to Google for analysis. The information collected will be used for providing, maintaining, and improving Google reCAPTCHA functionality and for general security purposes. Google reCAPTCHA will only be used by Zuora to fight spam and abuse of the Payment Pages 2.0 functionality. Google reCAPTCHA will not be used for any other purposes, such as determining credit worthiness, employment eligibility, financial status, or insurability of an end user. The data collected by the tool will not be used for personalized advertising by Google. Zuora does not use our customer’s data for any purpose other than to provide our services, such as Payment Pages 2.0.

We strongly encourage all Zuora’s customers to review Google reCAPTCHA’s terms of use and privacy policy as they include a requirement that applicable end users are explicitly informed that Google reCAPTCHA is being used on your page in accordance with Google’s Privacy Policy and Terms of Use. Each customer is also encouraged to work with your respective legal counsel to consider whether any changes are required to your current privacy compliance program in light of Google reCAPTCHA. 

Enable Google reCAPTCHA Enterprise on your website 

The following instructions provide guidance on configuring reCAPTCHA Enterprise site keys on a website for your reference. For detailed instructions, see Google reCAPTCHA Documentation.

Prerequisite 

You have created your own Google Cloud account and Google reCAPTCHA Enterprise account.

Procedures

  1. Choose the appropriate reCAPTCHA key type to use. Google reCAPTCHA Enterprise offers score-based keys and checkbox keys. Zuora recommends that you use the checkbox keys.
  2. Create site keys for your website to verify user interactions on your web pages.
  3. Based on the reCAPTCHA key type that you selected, install either checkbox site keys or score-based site keys on your website:
  4. Create an assessment.
  5. Interpret an assessment.

It is strongly recommended to implement CAPTCHA challenges on your login page and any other pages that can navigate to the web page with Zuora Payment Page iFrame.

For information on enabling the support for Google reCAPTCHA Enterprise on Payment Pages 2.0, see Support for CAPTCHA challenges in a later section.

Secure your Payment Pages 2.0 integration with Zuora security measures

To help reduce and manage your risks from potential card testing fraud, Zuora provides the following security measures:

This section provides guidance on enabling and configuring Zuora security measures for Payment Pages 2.0. For the latest sample code for Payment Pages 2.0 integration, see Sample Code for Payment Pages 2.0.

Prerequisites

Before you configure and use the security measures provided by Zuora for Payment Pages 2.0, complete the following tasks:

  1. Generate a new token and signature pair for each Payment Page 2.0 and Direct POST render.
  2. Ensure that you use the 1.3.1 or later version of zuora.js.

IP-based submission rate limiting

The IP-based submission rate limiting feature is a tenant-level security measure. It limits the number of times a hosted payment page can be submitted from the same IP address within a time range. This feature is enabled by default for your Payment Pages 2.0, including hosted payment pages set up through embedded iFrame and Direct POST requests. 

Access and configure this feature by navigating to Settings > Payments > Setup Payment Page and Payment Link > Rate Limiting Configuration. You can use the following settings to configure this feature. Ensure to configure the values within the allowed ranges that are described in the UI tooltips.

  • IP Whitelist: The whitelisted IP ranges that are not subject to the IP-based rate limiting configuration. You can specify a maximum of 50 IPv4 address ranges or 20 IPv6 address ranges.
    For scenarios such as call center agents, it is recommended to include approved IP addresses in the IP whitelist, instead of increasing the rate limiting values, to avoid any disruptions to legitimate service.
  • Submission Limit Per Minute: The number of times a page can be submitted per minute from the same IP.
  • Submission Limit Per Hour: The number of times a page can be submitted per hour from the same IP.

If the number of page submissions exceeds the thresholds, a Submit_Too_Quick error code error occurs. You can customize how you want to display the message for this error. For security considerations, it is not recommended that you alert users to your security setting details, such as the number of attempts to reach the error limit and the timeframe between submissions. See Error Handling for Payment Pages 2.0 and Customize error messages for Payment Pages 2.0 for more information.

Card-based submission rate limiting

The card-based submission rate limiting feature is a tenant-level security measure. It limits the times a hosted payment page can be submitted for the same card within a time range. The card-based rate limiting feature is enabled by default in all production environments and cannot be disabled. This feature is pre-configured by Zuora with a group of thresholds, including attempt times allowed within a minute, within an hour, and within a day. This feature is not available for self-configuration. If you want to know more information about this feature, submit a request at Zuora Global Support.

If the number of page submissions exceeds the thresholds, a Submit_Too_Quick error code error occurs. No more submissions are accepted from the same card until the beginning of the next time period. You can customize how you want to display the message for the error. For security considerations, it is not recommended that you alert users to your security setting details, such as the number of attempts to reach the error limit and the timeframe between submissions. See Error Handling for Payment Pages 2.0 and Customize error messages for Payment Pages 2.0 for more information.

For tests in production environments, it is recommended to use multiple cards or increase the time interval between submissions.

This feature is only supported in production environments. It cannot be enabled in any API Sandbox or Central Sandbox environments.

HPM submission rate limiting

The HPM submission rate limiting feature is a tenant-level security measure. This feature is enabled in all production environments by default. With this feature enabled, the maximum number of attempts to submit payment pages from the same tenant is configured by Zuora with a group of thresholds based on the normal peak traffic value of a tenant, including attempt times allowed within a minute, within an hour, and within a day. This feature is not available for self-configuration. If you want to know more information about this feature, submit a request at Zuora Global Support.

For example, a total of 100 submissions per hour is configured for a tenant. If the tenant makes 100 submissions in the first 10 minutes, this tenant cannot complete any more submissions until the hour has expired.

If the number of page submissions exceeds the thresholds, a Submit_Too_Quick error code error occurs. No more submissions are accepted from the same tenant until the beginning of the next time period. You can customize how you want to display the message for the error. See Customize error messages for Payment Pages 2.0 for more information.

If you plan or expect any activities with high-volume traffic, submit a request at Zuora Global Support before the activity. Zuora will evaluate your request and increase the thresholds for your tenant.

Support for CAPTCHA challenges

Zuora’s embedded iFrame solution supports Google reCAPTCHA Enterprise. Zuora provides two options, AI Assessment version and Interactive Test version, to support Google reCAPTCHA Enterprise score-based key and checkbox key respectively. For more information about reCAPTCHA Enterprise key types, see Google reCAPTCHA Enterprise Docs.

Google reCAPTCHA challenge feature supports the following endpoints:

For details about compatibility with browsers, see Browser support policy. Note that Google reCAPTCHA Enterprise on mobile (AI Assessment version and Interactive Test version) is supported only through browsers.

The following sections describe the support for Google reCAPTCHA services for the Payment Pages 2.0 iFrame solution. If you use Zuora’s Direct POST integration, ensure that you have implemented your own CAPTCHA for any hosted payment pages created to accept credit cards. See Best practices for Direct POST for more information.

Enable and configure Google reCAPTCHA on Payment Pages 2.0

Enable Google reCAPTCHA Enterprise for Payment Pages 2.0

If you use Zuora’s embedded iFrame solution, to enable Google reCAPTCHA Enterprise:

  1. On the configuration page for your payment page instance, navigate to the Security Information > Google reCAPTCHA section when you create or edit a Payment Page 2.0. 
  2. Enable either the Interactive Test (Checkbox) version or AI Assessment (Score-based) version by selecting the option. 

The following table describes the differences between these two versions. For details about the different versions of Google reCAPTCHA Enterprise, see Google reCAPTCHA Enterprise Docs.

  User interaction required? User interaction data on hosted page collected by Google? Corresponding Google reCAPTCHA Enterprise key type
AI Assessment No Yes Score-based site key
Interactive Test Yes No Checkbox site key

The Interactive Test version protects the website through more friction than the AI Assessment version. For maximum security, we recommend that you enable the Interactive Test version. In the interaction flow, the I'm not a robot checkbox is always displayed and end users must click the checkbox to verify that they are not robots. Then Google determines whether to show the CAPTCHA challenge window. The risk score is used to evaluate whether the attempt is a bot attack, but not used to determine whether to show the challenge window.

The following image is an example of the I'm not a robot checkbox:

captcha-checkbox.png

The following image is an example of the CAPTCHA challenge window:

challenge-example.png

For the AI Assessment version of Google reCAPTCHA Enterprise, the score returned by Google reCAPTCHA is based on user activity and data collected by Google algorithm. It is controlled by Google. Low risk score might be returned due to unusual traffic patterns or high volume requests. In your testing of payment pages that are configured with reCAPTCHA Enterprise AI Assessment version, the ReCaptcha_Validation_Failed error might occur as an expected behavior. 

To discover what happened during the reCAPTCHA validation such as the IP address used and the risk score returned by Google, use the HPM reCAPTCHA Validation Result data sources to export relative data. For more information, see HPM reCAPTCHA Validation Result data source.

Google reCAPTCHA Enterprise is supported globally. After reCAPTCHA Enterprise is enabled on your tenant, CAPTCHA challenges will be supported on your Payment Pages 2.0 even though the Google service is not accessible to your tenant.

For Payment Pages 2.0 implemented through iFrame, Zuora also provides an opt-in HPM Smart Bot Attacking Prevention feature to dynamically enable and configure reCAPTCHA Enterprise Interactive Test (Checkbox) version by Zuora when attacks are identified. For more information, see Dynamic enablement and configuration of Google reCAPTCHA.

Configure Google Cloud account for reCAPTCHA service

In Zuora, configure the Google Cloud account used for reCAPTCHA Enterprise by following these steps:

  1. Navigate to Settings > Payments > Setup Payment Page and Payment Link.
  2. On the Payment Pages tab page, navigate to the Google reCAPTCHA Enterprise Configuration section, and then click Edit.
  3. Select to use Google reCAPTCHA Enterprise with your own Google Cloud Enterprise account or Zuora’s Google Cloud Enterprise account. If you select to use Zuora’s Google Could Enterprise account, Zuora will generate a Google reCAPTCHA site key dedicated to your tenant for each type of the reCAPTCHA Enterprise service enabled on your tenant.
  4. If you decide to use your own account, configure the following credentials in the Google reCAPTCHA Enterprise Configuration section. You can obtain these fields from your Google reCAPTCHA Admin Console in Google Cloud Platform.

In your Google reCAPTCHA Admin Console, ensure the following configurations are completed:

  • Add your domains for both sandbox and production environments in the Google reCAPTCHA Domains setting.
  • The following settings are configured for the API Key on the Credentials page:
    • Application restrictions: The None option is selected.
    • API restrictions: The Restrict key option is selected and reCAPTCHA Enterprise API is selected.

For more information, see Google reCAPTCHA developer documentation.

If you are using Zuora Central Sandbox, you must reconfigure the Google Cloud account used for reCAPTCHA Enterprise after Central Sandbox is refreshed.

Configure Google reCAPTCHA Enterprise for Payment Pages 2.0

For both AI Assessment and Interactive Test versions of Google reCAPTCHA Enterprise, you can configure the tenant-level and page-level Risk Score Threshold settings to set up thresholds for the level of risk the user interaction poses. Details about the allowed value are available in the UI tooltip. The Risk Score Threshold value configured in Zuora HPM settings is used to evaluate whether the attempt is a bot attack, but not used to determine whether to show the CAPTCHA challenge. For the recommended value, refer to the recommendations by Google. For more information about the risk score recommendation and interpretation, see Google Cloud Docs.

  • To configure the tenant-level Risk Score Threshold setting:
    1. Navigate to Settings > Payments > Setup Payment Page and Payment Link.
    2. On the Payment Pages tab page, click Edit in the Google reCAPTCHA Enterprise Configuration section.
    3. Enter a value in the Risk Score Threshold field, and click Save.
  • To configure the page-level Risk Score Threshold setting: 
    1. Navigate to the Security Information > Google reCAPTCHA section when creating or editing a Payment Page 2.0. 
    2. Click the Interactive Test (Checkbox) or AI Assessment (Score-Based)  option according to your needs. The Risk Score Threshold field is displayed under the option. 
    3. Enter a value in the Risk Score Threshold field. If no value is set for this setting, the tenant-level Risk Score Threshold value will be used for your hosted payment page. This page-level value takes precedence over the tenant-level Risk Score Threshold value.

Disable Google reCAPTCHA

When you create or edit a Payment Page 2.0, navigate to the Security Information > Google reCAPTCHA section and click Disable reCAPTCHA to disable the Google reCAPTCHA service on your Payment Page 2.0.

Migrate from reCAPTCHA v2 Classic to reCAPTCHA Enterprise

The support for reCAPTCHA v2 Classic in Payment Pages 2.0 has been deprecated since 8 November 2022. reCAPTCHA Enterprise Interactive Test (Checkbox) version is recommended as the replacement solution for an improved bot detection experience and to avoid failures due to exceeding the reCAPTCHA quota. If you did not migrate to reCAPTCHA Enterprise before 8 November 2022, reCAPTCHA is disabled on your tenant. Though you can still enable reCAPTCHA Enterprise, your tenant is not protected by the reCAPTCHA service until you enable it.

Migrate to reCAPTCHA Enterprise Interactive Test (Checkbox) version by completing both of the following tasks:

  • Update your client code for handling the CAPTCHA challenge user interaction to support the flow of reCAPTCHA Enterprise Interactive Test (Checkbox) version.
  • Update your hosted payment page setting in Zuora.

Because the user interaction flows for these two versions of reCAPTCHA services are different, you must update your client code to support the flow for reCAPTCHA Enterprise Interactive Test (Checkbox) version. For reCAPTCHA Enterprise Interactive Test (Checkbox) version, if CAPTCHA challenges are required, end-users resolve the challenges first, and then click the submit button to submit the hosted payment page. You can use the onCaptchaStateChange event handler to implement your logic.

For example, you have integrated your hosted payment page through the Button Outside mode. To support the reCAPTCHA v2 Classic service, you implemented the logic in the onCaptchaStateChange event to remove an overlay when the challenge displays and add the overlay back after the challenge is resolved by the end-user. You now want to migrate to reCAPTCHA Enterprise Interactive Test (Checkbox) version. To support the interaction flow, you must update your code by removing the logic of handling the overlay before the end-user resolves the challenge.

In addition to the client code update, update your hosted payment page setting in Zuora by following these instructions:

  1. Click Edit to open the settings page of your Payment Page 2.0 in the editing mode.
  2. In the Security Information > Google reCAPTCHA section, click Google reCAPTCHA Enterprise - Interactive Test (Checkbox).
  3. Enter a value for the Risk Score Threshold setting. You can find detailed information about the configuration settings through the UI tooltip.
  4. Save your Payment Page 2.0.

Alternatively, you can enable the HPM Smart Bot Attacking Prevention feature through Zuora Global Support. HPM Smart Bot Attacking Prevention is an opt-in auto-adjusting security feature that dynamically enables and configures reCAPTCHA Enterprise when attacks are identified. See Dynamic enablement and configuration of Google reCAPTCHA for more information.

Google CAPTCHA challenge not displaying problem

After you have enabled the support for Google reCAPTCHA service on your tenant through the Payment Pages 2.0 settings and implemented the Google reCAPTCHA service on your page, sometimes the CAPTCHA symbol appears but the challenge does not show. The presence of the CAPTCHA symbol indicates that Google CAPTCHA is loaded. Whether to display the CAPTCHA challenge is decided by Google. If you want to test your CAPTCHA implementation, using an incognito browser window might increase the chances of displaying the challenge.

Dynamic enablement and configuration of Google reCAPTCHA

For Payment Pages 2.0 implemented through iFrame, Zuora provides the HPM Smart Bot Attacking Prevention feature, which is an opt-in auto-adjusting security feature based on continuous monitoring of attack patterns. With this feature enabled, Zuora dynamically enables and configures reCAPTCHA Enterprise Interactive Test (Checkbox) version when attacks are identified.

According to the hourly monitoring results, when Zuora identifies that a hosted payment page is under attack, Zuora evaluates whether the current reCAPTCHA settings can secure the hosted payment page. If your current reCAPTCHA settings are not sufficient to secure your page, Zuora automatically enables reCAPTCHA Enterprise Interactive Test version and increases the page-level Risk Score Threshold value if necessary. When Zuora finds the bot attack is over, the reCAPTCHA security settings are restored to the latest enablement status and value that you configured. During the attack, if you change your reCAPTCHA security settings, after the attack Zuora restores the values to your latest settings configured during the attack but not to your initial settings before the attack.

Before enabling the HPM Smart Bot Attacking Prevention feature, ensure that you have tested reCAPTCHA Enterprise Interactive Test version on your hosted payment page and that at least one submission has been made successfully over the past 30 days. In some cases (for example, if your Submit button is outside of your hosted payment page), the HPM Smart Bot Attacking Prevention feature might attempt to enable a CAPTCHA challenge that is incompatible with your process flow. If you have any questions about this feature, submit a request at Zuora Global Support.

To enable the HPM Smart Bot Attacking Prevention feature for your hosted payment page, complete the following steps:

  1. When creating or editing a Payment Page 2.0, navigate to Security Information > Google reCAPTCHA.
  2. Select Smart Bot Attack Prevention and save your configuration.

To discover when and what reCAPTCHA settings are adjusted, use the HPM Smart Bot Attacking Prevention Audit data sources to export relative data. For more information, see HPM Smart Bot Attacking Prevention Audit data source.

This auto-adjusting security mechanism is not supported for Payment Pages 2.0 implemented through Direct POST.

Token expiration

The Token Expiration feature is a page-level security measure. With this feature enabled, when end-users hit this threshold by repeatedly submitting incorrect information on the hosted payment page, they will see the error message and will be blocked from all further hosted payment page submissions.

Enable this feature by setting a positive integer value for the Limit the number of submissions before blocking submission field. This feature is automatically enabled for your Payment Pages 2.0. It is pre-configured by Zuora with a default threshold. You can configure the threshold through Zuora UI.

Access and configure this feature by completing the following steps:

  1. When creating or editing a Payment Page 2.0, navigate to the Security Information > Token Expiration section.
  2. Enter a positive integer in the Limit the number of submissions before blocking submission field. Details about the allowed value are available in the UI tooltip.

When the value of the Limit the number of submissions before blocking submission field is exceeded, the Submit button is not disabled. However, subsequent requests are not sent to the gateway even if end users click Submit. Zuora directly responds with an error message and error code to inform end-users that they have tried too many times. When the submission threshold is reached, you need to regenerate a signature and provide end customers with a way to re-render the page.

If the number of page submissions exceeds the configured thresholds, an Attempt_Exceed_Limitation error occurs. You can customize how you want to display the message for this error. See Error Handling for Payment Pages 2.0 and Customize error messages for Payment Pages 2.0 for more information.

Note that 3DS2 authentication exceptions also cause token expiration. On the next submission after a 3DS2 authentication exception occurs, the Attempt_Exceed_Limitation error occurs.

For more information about token generation, management, and usage analysis, see Generate and manage the Digital Signature and Token for Payment Pages 2.0.

Since 8 November 2022, Zuora has automatically enabled the Token Expiration feature on tenants that have not yet implemented this anti-fraud measure. The Limit the number of submissions before blocking submission field is set to a default value if your previous value is out of the range 1 - 10. If you previously had a value of 0 for this setting, you must implement a token refresh function in your code to handle the token expiration scenario (see related sample code for reference). If you have any questions about this auto-enablement, contact Zuora Global Support.

Notes for the Inline Button Outside integration mode

For the Inline Button Outside integration mode, if Google reCAPTCHA is not enabled, the RSA Signature Token Expiration feature is not supported. When a Payment Page submission fails, the end-user is redirected to the callback page that you configured on Payment Page configuration page. If both Google reCAPTCHA and Token Expiration are enabled, the Token Expiration feature takes effect and the configured callback URL will not be triggered until the token expiration limit is reached. If you want to ignore the token expiration setting to redirect end-users to the callback page the first time when the page submission fails, contact Zuora Global Support.

Support for 3D Secure

3D Secure is the abbreviation for Three Domain Secure, which is the payment industry’s Internet Authentication Standard. The Strong Customer Authentication regulation requires the use of 3D Secure for card payments in the United Kingdom and the European Economic Area. 3D Secure requires end users to complete an additional verification step when making a payment.

To ensure enhanced security and strong authentication for end users and merchants in the regions where 3D Secure is required, Zuora integrates with applicable payment gateways to support both 3D Secure 2.0 and 1.0 for Payment Pages 2.0. Since Zuora’s support for 3D Secure 1.0 is no longer under active development, it is strongly recommended to use 3D Secure 2.0 for your hosted payment pages.

3D Secure 2.0 is the latest version of the 3D Secure standard and it is one of the requirements of PSD2. To enable 3D Secure 2.0 for your Payment Pages 2.0, complete the following steps:

  1. When creating or editing a Payment Page 2.0, navigate to the Security Information > 3D Secure section.
  2. Select Enable 3D Secure 2.0.

For more information about 3D Secure 2.0, see PSD2 and SCA overview and Zuora's implementation of 3D Secure 2.0. The "Best practices" section in Zuora’s implementation of 3D Secure 2.0 also provides best practices for reducing the possibility of failed transactions due to 3DS2 authentication errors.

3D Secure 1.0 is the older version of 3D Secure standard. It is recommended to use 3D Secure 2.0 for your Payment Pages 2.0 as the replacement. The support for 3D Secure 1.0 is in Controlled Release. If you have any questions about 3D Secure 1.0, submit a request at Zuora Global Support. For more information about 3D Secure 1.0, see 3D Secure 1.0 for Payment Pages 2.0.

Client-side Payment Page parameter validation

The Client-side Payment Page Parameter Validation feature is a tenant-level security measure to better protect the client-side parameters in the request for rendering or submitting Payment Pages 2.0. 

Zuora recommends that you enable this security measure:

  1. Navigate to Settings > Payments > Setup Payment Page and Payment Link > Advanced Configuration.
  2. On the Payment Pages tab page, click Edit in the Advanced Configuration section.
  3. Select Validate Client-Side HPM Parameters, and then click Save

After this feature is enabled, when receiving a request for rendering or submitting a hosted payment page, Zuora validates the client parameters in the request by comparing the value in the request with the value specified in the digital signature. Therefore, you must specify these parameters when calling the REST Generate RSA signature operation for generating the digital signature.

When specifying the client parameters in the Generate RSA signature operation, if the parameter name contains field_ , use only the string after field_ as the field name. For example, field_currency is a supported client parameter. In the Generate RSA signature operation, use currency  instead of field_currency. The field name that can be supported by the Generate RSA signature operation is documented in the API Reference.

Note that the following client parameters in client parameters are not supported by the Client-side HPM Parameter Validation feature:

  • The following three parameters are not supported because they are only used to control the display in the UI:
    • retainValues
    • countryBlackList
    • countryWhiteList
  • The url parameter is also not supported because it was already validated.

If the parameters contained in the rendering or submission request can match the value specified in the digital signature, the validation succeeds. If they do not match, the validation fails. The Validate_Dynamic_Params_Failed error code is returned, and Zuora blocks the rendering or submission request. 

Here is a sample Curl request to generate a token and a digital signature. paymentGateway and locale are the client parameters specified for validation.

curl -i -k -H "apiAccessKeyId:superadmin@myCompany.com" -H "apiSecretAccessKey:password" -H "Accept:application/json" -H "Content-Type:application/json" -X POST https://rest.zuora.com/v1/rsa-signatures -d '
{
   "uri": "https://www.zuora.com/apps/PublicHostedPageLite.do",
   "method": "POST",
   "pageId":"ff80808145b3bf9d0145b3c6812b0008",
   "paymentGateway":"Orbital7",
   "locale":"fr_CA"
}';

Support for Address Verification Service

Zuora Payment Pages 2.0 supports the billing address fields in the payment page form. If the gateway provider offers Address Verification Service (AVS), the address information entered by the end user in your payment page form will be passed to the gateway and compared with the cardholder's billing address on record with the card issuer.

Support for Email address verification

Zuora Payment Pages 2.0 supports the email address field in the payment page form. If the gateway provider offers the verification service of email addresses, the email address information entered by the end user in your payment page form will be passed to the gateway and compared with the cardholder's email address on record with the card issuer.

Zuora Fraud Protection

Zuora integrates with Microsoft Dynamics 365 Fraud Protection and provides an opt-in payment fraud protection service, called Zuora Fraud Protection. For more information, see Zuora Fraud Protection.

HPM Threat Detection dashboard

Zuora System Health dashboard for Hosted Payment Method Pages (HPM Threat Detection dashboard) collects and displays HPM traffic and threat data, as well as security settings configured for each hosted payment page. In the HPM Threat Detection dashboard, data about hosted payment pages on your Zuora tenant within a time range are available for you to detect attacks and other issues and then troubleshoot. For details about this dashboard, see HPM Threat Detection dashboard.

Export Zuora security measure data for validation or auditing

To discover the issues that happened during a Payment Page 2.0 submission, you can use the following data sources to export data for further analysis. Open the following links to find details about how to use the data source.

An example for securing a Payment Page 2.0

Here is an example of implementing security measures for a Payment Page 2.0:

  1. To protect your user account, implement one of the following security measures to protect your user account signup and login from malicious use of fake email address or phone number to register as a new user:
    • Email MFA
    • SMS MFA
  2. Implement CAPTCHA challenges on your login page and any other pages that can navigate to the web page with Zuora Payment Page iFrame.
  3. When configuring the tenant-level Payment Page 2.0 settings, complete the following configurations:
    • Configure your own Google Cloud Enterprise account credentials.
    • If you use client parameters in your request for rendering or submitting a hosted payment page, enable Validate Client-Side HPM Parameters.
  4. When creating or editing a Payment Page 2.0, enable and configure the following security measures provided by Zuora:
    • Configure the Token Expiration feature by setting 3 for the Limit the number of submissions before blocking submission field.
    • Enable the Google reCAPTCHA Enterprise checkbox version on your hosted payment page by selecting the option and setting 0.85 for the Risk Score Threshold field.
    • If the gateway supports 3D Secure 2.0, enable it for your hosted payment page by selecting this option.
  5. Customize how you want to display the messages for the following error codes based on the fields that caused the error:
    • Attempt_Exceed_Limitation
    • ReCaptcha_Validation_Failed
    • Submit_Too_Quick

For detailed instructions on each step, see Protect your website and user accounts and Secure your Payment Pages 2.0 integration with Zuora security measures in the preceding sections.