We will continue to update this page as soon as more information and integration details are available from our payment gateway partners. If you have any question, reply in the Community post or reach out to your gateway provider directly.
As an integrator between merchants and payment gateways, Zuora helps to manage your payment flows in the subscription business. Zuora enables integrations to payment service providers, such as payment gateways and processors, which in turn communicate with the issuing bank. It is ultimately the issuing bank who determines whether a card needs to be authenticated or not.
To be compliant with PSD2, payment gateways must also support SCA. 3DS2 is seen as the standard to support SCA. Zuora ensures that you have the visibility on the status of payment gateways. When a payment gateway is ready to support 3DS2, Zuora will also include or enhance the integration with the gateway to support 3DS2.
Payment gateway support for 3DS2
Zuora integrates with the 3DS2 solution of the following payment gateways:
|Payment gateway||Payment gateway integrations in Zuora||Support for 3DS2?|
|Adyen||Adyen Integration v2.0|
|BlueSnap||BlueSnap, Payment API v2.0|
|CyberSource||CyberSource, Payment API v2.0|
|CyberSource Enterprise Gateway, API v1.97|
|CyberSource Enterprise Gateway, API v1.28|
|GlobalCollect (WebCollect Merchant Link)|
|PayPal Payflow Pro|
|PayPal Express Checkout|
|JPMorgan Chase Paymentech Orbital||Chase Paymentech Orbital Gateway|
|Chase Paymentech Orbital Gateway, API v7.0.1|
|Chase Paymentech Orbital Gateway API v.6.4.4|
|Chase Paymentech Orbital Gateway, API v6.3.0|
|WorldPay (Corporate Gateway)|
In the preceding table, the gateway integration versions for which Zuora does not provide 3DS2 support may require a gateway integration version upgrade, gateway migration, or an additional feature to enable the 3DS2 functionality. Zuora recommends you contact your gateway representatives directly.
Zuora is currently not planning to support 3DS2 for all other payment gateways because they claimed that they are out of the scope of PSD2. If these gateways become subject to PSD2 requirements and inform Zuora with their 3DS2 integration, Zuora plans to provide 3DS2 support for these integrations at a later time.
Updates from Zuora
3DS2 authentication through Payment Pages
When configuring Payment Pages, an additional setting called Enable 3D Secure 2.0 is added.
With this setting enabled, Payment Pages will go through 3DS2 authentication service provided by the payment gateway.
Required updates from you
To be compliant with PSD2, you must make the following changes:
- Check if your gateway instance supports 3DS2 as documented in Payment gateway support for 3DS2. If it does not support 3DS2, switch your gateway provider or upgrade your gateway instance to a version that supports 3DS2.
- Ensure that you are on Payment Pages 2.0.
- Ensure that you adopt the Stored Credential Transaction framework. It is a requirement of strong customer authentication exemptions. Without stored credential transactions enabled, the payments processed through your tenant are not exempted from SCA and will fail.
- Update your configuration for Payment Pages 2.0. Zuora supports 3DS2 via the embedded iFrame of Payment Pages 2.0 if the gateway you use is in the preceding table.
If Direct POST is used, you should implement 3DS2 for your website outside Zuora. As such, you take full control of the card authentication and authorization flow. After you get the networkTransactionId from the gateway, pass through the credit card data along with several required fields for merchant initiated transactions (MITs) to Zuora through Direct POST. See Direct POST Form Fields for Payment Pages 2.0 for the detailed request fields. Note that do not select the Enable 3D Secure 2.0 checkbox on your Payment Page 2.0 configuration page since 3DS2 has been implemented outside Zuora.
- For merchants advised by their payment gateways to pass in an order value or authentication amount, Zuora’s implementation does not distinguish between an authorization and an authentication amount. To make this distinction, you have to specify a value for the
authorizationAmountfield, the client-side HPM parameter in the request for rendering Payment Pages 2.0. Some payment gateways recommend $0 authorizations. Thus you must ensure that your merchant account is also configured to allow for the $0 authorization.
- A website overlay is often used to display the progress after a form is submitted through the iFrame of your Payment Page. However, after 3DS2 is introduced, overlays can block customers from performing strong customer authentication. Therefore, to facilitate the authentication process, you should remove any overlay that may potentially block the iFrame when integrating with Zuora’s Payment Pages 2.0.
- The issuing bank takes full control of the authentication page. If the authentication page is not displayed properly, a more time-efficient way is to contact both your gateway representative and Zuora Global Support. It is because payment gateways work directly with banks, and can quickly provide assistance.
Meanwhile, Zuora recommends you to prompt your customers to retry with a different credit card when this issue occurs.
- To ensure your customers can interact smoothly when being challenged, we strongly recommend that you pass a custom function as the last parameter in the
Z.renderWithErrorHandlerPayment Page render function. This custom function is used to remove possible overlays. For example, define the removeModalLayer function to be passed in
Z.renderWithErrorHandler(params, prepopulateFields, callback, clientErrorMessageCallback, null, null, removeModalLayer);
After getting the response from the issuing bank, Zuora will call the removeModalLayer function to remove the overlay and display the challenge form. For more information, see Render Payment Pages 2.0 with Custom Error Handling.
Ensure that the
displaystyle attribute of the container for the Payment Pages form is not set to
none. If you implement logic to hide the container for a certain reason, ensure to include the logic of displaying the container again.