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. 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:

On 22 September 2022, Zuora will automatically enable both reCAPTCHA Enterprise and RSA Signature Token Expiration on all production tenants that have not yet implemented these anti-fraud measures. This change will go live on sandbox environments in stages from 6 September 2022 through 8 September 2022. For more information, see Support for CAPTCHA challenges and Token expiration.

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:

  • IP-based rate limiting
  • Card-based rate limiting
  • Support for Google reCAPTCHA challenges
  • Token expiration
  • Support for 3D Secure
  • Client-side Payment Page parameter validation
  • Address Verification Service
  • Email address verification

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 automatically enabled 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 Hosted Pages > 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.

Support for CAPTCHA challenges

Zuora’s embedded iFrame solution supports the following versions of Google reCAPTCHA services.

Google reCAPTCHA version Description

Google reCAPTCHA Enterprise

(Recommended)

Zuora supports both score-based (no challenge) and checkbox (checkbox challenge) site keys.

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 Cloud Docs.

On 22 September 2022, Zuora will automatically enable Google reCAPTCHA Enterprise on all production tenants that have not yet implemented either version of reCAPTCHA Enterprise. The Google reCAPTCHA Enterprise - Interactive Test (Checkbox) version will be enabled, which will default to using Zuora’s credentials. Starting from 22 September 2022, Zuora’s customers will no longer be able to disable Google reCAPTCHA. Customers using Direct POST will not need to make any additional configurations and Zuora will not enforce reCAPTCHA on those payment pages. This change will go live on sandbox environments in stages from 6 September 2022 through 8 September 2022. If you have any questions about this planned change, contact Zuora Global Support.

Google reCAPTCHA v2 Classic

If you have enabled reCAPTCHA v2 Classic before, you can continue using it on production tenants until 22 September 2022 (available on sandbox tenants until 6 September 2022). It is strongly recommended to switch to reCAPTCHA Enterprise before then. See Migrate from reCAPTCHA v2 Classic to reCAPTCHA Enterprise for details.

Google reCAPTCHA challenge feature is supported with the following endpoints:

For details about compatibility with browsers, see Browser support policy.

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. 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 Interactive Test version protects the website through more friction than the AI Assessment version. For maximum security, we strongly recommend that you enable the Interactive Test version.

The following table describes the differences between these two versions.

  Interactive CAPTCHA test when threshold exceeded? 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

After Google reCAPTCHA 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 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. 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 Hosted Pages > Google reCAPTCHA Enterprise Configuration.
    2. Click Edit.
    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.

Configure reCAPTCHA v2 Classic for Payment Pages 2.0

If you have enabled reCAPTCHA v2 Classic before, you can continue using it on production tenants until 22 September 2022 (available on sandbox tenants until 6 September 2022). It is strongly recommended to switch to reCAPTCHA Enterprise before then. See Migrate from reCAPTCHA v2 Classic to reCAPTCHA Enterprise for details.

If Google reCAPTCHA v2 Classic has been enabled on your tenant, you can configure the Limit the number of submissions before CAPTCHA Challenge setting to set up a threshold for the scenario that end users will not be challenged before they submit the incorrect information on hosted payment pages as many times as the threshold value. You can find detailed information about the configuration settings through the UI tooltip.

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. See Error Handling for Payment Pages 2.0 and Customize error messages for Payment Pages 2.0 for more information.

The Limit the number of submissions before CAPTCHA Challenge setting is not supported for the Inline Button Outside mode.

Disable Google reCAPTCHA

When you create or edit a Payment Page 2.0, navigate to the Security Information > Google reCAPTCHA section and configure the following settings to disable Google reCAPTCHA for different scenarios:

  • Disable reCAPTCHA: Click this field to disable the Google reCAPTCHA service on your Payment Page 2.0.
  • Submit hosted page requests via DirectPOST: Select this field to utilize the current page for Direct POST submissions and prevent CAPTCHA challenges from interacting with your Direct POST requests. If this setting is not selected, your Payment Page 2.0 implemented through Direct Post could experience unhandled errors.

Starting from 22 September 2022, options listed above in this section will no longer be available on production tenants. Zuora will not allow disabling Google reCAPTCHA Enterprise. Customers using Direct POST will not need to make any additional configurations and Zuora will not enforce reCAPTCHA on those payment pages. This change will go live on sandbox environments in stages from 6 September 2022 through 8 September 2022.

Configure Google Cloud account for reCAPTCHA service

For both Google reCAPTCHA Enterprise and reCAPTCHA v2 Classic, you can configure your own Google Cloud account credentials when configuring the tenant-level Hosted Pages settings. Alternatively, you can select to use Zuora’s Google Cloud Enterprise account.

Configure Google Cloud account for reCAPTCHA Enterprise

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

  1. Navigate to Settings > Payments > Setup Hosted Pages.
  2. In the Google reCAPTCHA Enterprise Configuration section, click Edit.
  3. Select to use Google reCAPTCHA Enterprise with your own Google Cloud Enterprise account or Zuora’s Google Cloud Enterprise account.
  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.

Configure Google Cloud account for reCAPTCHA v2 Classic

If you have enabled reCAPTCHA v2 Classic before, you can continue using it on production tenants until 22 September 2022 (available on sandbox tenants until 6 September 2022). However, it is strongly recommended to switch to reCAPTCHA Enterprise before then. See Migrate from reCAPTCHA v2 Classic to reCAPTCHA Enterprise for details.

To configure the Google Cloud account used for reCAPTCHA v2 Classic:

  1. Navigate to Settings > Payments > Setup Hosted Pages

  2. In the Google reCAPTCHA v2 Keys Configuration section, click Edit.

  3. Configure your own Site Key and Secret Key for Google reCAPTCHA service. You can obtain these fields from your Google reCAPTCHA Admin Console. For more information, see Google reCAPTCHA developer documentation. Note that you have to add your domains for both sandbox and production environments in the Google reCAPTCHA Domains setting. 

If the credentials are not provided, Zuora’s Google Cloud account and settings will be used by default.

Migrate from reCAPTCHA v2 Classic to reCAPTCHA Enterprise

If you are using reCAPTCHA v2 Classic, it is strongly recommended to switch to reCAPTCHA Enterprise Interactive Test (Checkbox) version for an improved bot detection experience and to avoid failures due to exceeding the reCAPTCHA quota. Follow these instructions to migrate from reCAPTCHA v2 Classic to reCAPTCHA Enterprise Interactive Test version for your hosted payment pages:

  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.

After reCAPTCHA Enterprise is enabled, you can no longer switch back to reCAPTCHA v2 Classic.

Set up the event handler for processing CAPTCHA interaction

If you have implemented a loading overlay after form submission, you can use the event handler function Z.setEventHandler to support the end-user interaction with the CAPTCHA challenge.

Z.setEventHandler("onCaptchaStateChange", function(event) {
        if (event.visible) {
                // When CAPTCHA is visible, remove the loading overlay so that the end-user can interact with CAPTCHA
        } else {
                // When CAPTCHA is invisible once the challenge completes, display the loading overlay again
        }
});

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.

This feature is in the Early Adopter phase. We are actively soliciting feedback from a small set of early adopters before releasing it as generally available. If you want to join this early adopter program, submit a request at Zuora Global Support to enable the HPM Smart Bot Attacking Prevention feature.

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.

If you have any questions about this feature, submit a request at Zuora Global Support.

Token expiration

You can enable the RSA Signature Token Expiration feature by setting a positive integer for the Limit the number of submissions before blocking submission field. 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.

To enable the RSA Signature Token Expiration feature 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 > 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.

The RSA Signature Token Expiration feature is not supported for the Inline Button Outside mode.

On 22 September 2022, Zuora will automatically enable the RSA Signature Token Expiration feature on all production tenants that have not yet implemented this anti-fraud measure. The Limit the number of submissions before blocking submission field will be set to a default value. This change will go live on sandbox environments in stages from 6 September 2022 through 8 September 2022. If you have any questions about this planned change, 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 Hosted Pages > Advanced Configuration.
  2. Click Edit, 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.

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:
    • Enable 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.