Skip to main content

Advanced Security Measures for Payment Pages 2.0

Zuora

Advanced Security Measures for Payment Pages 2.0

For tighter security around Payment Pages 2.0, Zuora supports additional security measures. 

Prerequisites

To configure advanced security measures for Payment Pages 2.0, you must complete the tasks in the following checklist to set up the Payment Page:

  1. Generate a new signature for each Payment Page and Direct POST render. 
    • Generate a new signature in your callback page if you want to re-render a Payment Page in the Inline Button Outside mode when a previous submission fails. Your callback page will usually try to re-render page when submission failed.
    • If you Implement Payment Pages 2.0 via Direct POST, generate a new signature for each Direct POST request that is sent to Zuora. 
  2. Customize the error messages for the Attempt_Exceed_Limitation, ReCaptcha_Validation_Failed, and Submit_Too_Quick error codes. 
    See Error Handling for Payment Pages 2.0 for more information.
  3. If the CAPTCHA challenge feature is enabled, ensure that elements surrounding the hosted page should support changes in the embedded iFrame width and height.
  4. Ensure that you use the 1.3.0 or later version of zuora.js.

The Inline Button Outside mode only supports Three Domain Secure (3D Secure) on Payment Pages 2.0. If you are using this mode, you cannot limit the number of Payment Page submissions before CAPTCHA challenge or limit the number of Payment Page submissions before blocking submissions for security measures.

Secure your Payment Pages 2.0

To help reduce and manage your risk from potential credit card fraud, Zuora strongly recommends that you enable the CAPTCHA Challenge feature and configure the proper rate limiting for your Payment Pages.

IP-based and card-based rate limiting

Zuora provides tenant-level IP-based and Card-based rate limiting capabilities to help you manage fraud and malicious use of Payment Pages. See Configure Payment Pages 2.0 for more information.

Configure Google reCAPTCHA

“Completely Automated Public Turing test to tell Computers and Humans Apart” (CAPTCHA) is a type of challenge-response test used in computing to determine whether or not the user is human. The CAPTCHA challenge protects you against potential automated abuse of Payment Page submissions.

Enable Google reCAPTCHA

Zuora’s embedded iFrame solution supports the following versions of Google reCAPTCHA services. For details about compatibility with the browsers, see Browser Support Policy.

  • Google reCAPTCHA Enterprise, including both score-based (no challenge) and checkbox (checkbox challenge) site keys

    Zuora provides two options, AI Assessment mode and Interactive Test mode, to support Google reCAPTCHA Enterprise score-based key and checkbox key respectively. For more information about reCAPTCHA Enterprise key types, see Google Cloud Docs.

  • Google reCAPTCHA v2 Classic

    If you have enabled reCAPTCHA v2 Classic before, you can continue using it. However, it is strongly recommended to switch to reCAPTCHA Enterprise. See Migrate from reCAPTCHA v2 Classic to reCAPTCHA Enterprise for details.

If you use Zuora’s embedded iFrame solution, to enable Google reCAPTCHA Enterprise, navigate to the Security Information > Google reCAPTCHA section when you create or edit a Payment Page 2.0, and then enable either the AI Assessment (Score-based) mode or Interactive Test (Checkbox) mode by selecting the option. The following table describes the differences between these two modes.

  Interactive CAPTCHA test required? User interaction data on hosted page collected by Google? Corresponding Google reCAPTCHA Enterprise key type
Interactive Test mode Yes No Checkbox site key
AI Assessment mode No Yes Score-based 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.

If you use Zuora’s Direct POST integration, ensure that you have implemented your own CAPTCHA for any Payment Pages created to accept credit cards. It is recommended to implement the following security measures. See Best practices for Direct POST for more information.

  • Enforce CAPTCHA or other bot/fraud detection prior to the first submission.
  • Limit the rate of submissions from individual submission sources. For example, no more than 3 submissions per minute from a single source.

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.
  • 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 implemented through Direct Post could experience unhandled errors.

Configure reCAPTCHA v2 Classic

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 the end users will not be challenged before they submit the incorrect information on Payment Pages as many times as the threshold value. After they hit this threshold, they will see the CAPTCHA challenge page displayed in every submission attempt. They must pass the CAPTCHA challenge for every subsequent Payment Page submission. 

The value of the Limit the number of submissions before CAPTCHA Challenge field must be equal to or greater than 0, and it must be equal to or less than the value of the Limit the number of submissions before blocking submission field. The recommended value is 0.

The CAPTCHA challenge page is displayed even after the number of Payment Page submission failures exceeds the value of the Limit the number of submissions before blocking submission field to slow down the frequency of potential attacks.

To use the reCAPTCHA v2 Classic Challenge feature, you must use the following endpoints:

If the number of page submissions exceeds the configured threshold, an error occurs. See Submit_Too_Quick error code for more information.

Configure reCAPTCHA Enterprise

For both AI Assessment and Interactive Test modes of Google reCAPTCHA Enterprise, you can configure the page-level Risk Score Threshold setting to set up a threshold for the level of risk the user interaction poses. The value must be in the range 0.01 - 1, with one or two decimal places. Google suggests starting the risk score threshold from 0.5. If no value is set for this setting, the tenant-level Risk Score Threshold value will be used for your Payment Page. This page-level value takes precedence over the tenant-level Risk Score Threshold value. For more information about the tenant-level setting, see Configure Payment Pages 2.0.

For more information about the risk score interpretation from Google, see Google Cloud Docs.

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) mode, 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 mode for your Payment Pages.

  1. Click Edit to open the editing page for your Payment Page 2.0.
  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. Google suggests starting the risk score threshold from 0.5. For more information on configuring the risk score threshold, see Configure reCAPTCHA Enterprise.
  4. Save your Payment Page 2.0.

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

Google CAPTCHA challenge not displaying problem

After you have enabled the support for Google reCAPTCHA service on your tenant through the Payment Page settings and implemented the Google reCAPTCHA service on your page, sometimes the problem that the CAPTCHA symbol appears but the challenge does not show might occur. 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.

Configure 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 in the Zuora UI. With this feature enabled: 

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. 

  1. The value of the Limit the number of submissions before blocking submission field must be greater than the value of the Limit the number of submissions before CAPTCHA Challenge field. Otherwise, CAPTCHA challenge will not work leading to a possible attack.
  2. It is not recommended to set the value of the Limit the number of submissions before blocking submission field to 0.

For the value of the Limit the number of submissions before blocking submission field, it is recommended to use a low value, preferably between 1 and 3. The maximum value allowed is 10.

  • For a value of 1: The token expires immediately upon submission of the Payment Page, which triggers a callback to your server.
  • For a value of 3: The token expires immediately upon the third submission of the Payment Page, which triggers a callback to your server.

If the number of page submissions exceeds the configured threshold, an error occurs. See Attempt_Exceed_Limitation error code for more information.

Enable 3D Secure

Enable 3D Secure 1.0

This feature is in Controlled ReleaseSubmit a request at Zuora Global Support to get this feature enabled for your tenant.

With this feature, Zuora will perform the 3D Secure check for Visa, MasterCard, and American Express credit cards. 

To use the 3D Secure feature, you must select the Verify new credit card check box on the corresponding payment gateway configuration page. Otherwise, 3D Secure will not be performed even if you enable the 3D Secure feature.

For more information, see 3D Secure for Payment Pages 2.0.

Enable 3D Secure 2.0

Zuora supports 3D Secure 2.0 for Payment Pages 2.0. 3DS2 is the solution of strong customer authentication (SCA) and requires you to send additional data with each transaction so that the bank can validate if the transactor is the actual cardholder. Select the Enable 3D Secure 2.0 checkbox to enable 3D Secure 2.0.

See Zuora's implementation of 3D Secure 2.0 for more information.

Set up 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
        }
});

Customize error messages for error codes

You can customize how you want to display the messaging for the following error codes based on the fields that caused the error:

  • Attempt_Exceed_Limitation
  • ReCaptcha_Validation_Failed
  • Submit_Too_Quick

For more information, see Error Handling for Payment Pages 2.0.