Zuora Release 2022.07.R2

Resolved: Formula Injection vulnerability issue when exporting product data

Previously, Formula Injection vulnerability existed when you exported product data files in Excel (.xls) by clicking the more options icon  and then clicking Export this product on the product details page through the Zuora UI.

The Formula Injection vulnerability has now been resolved. If you export a product data file using the abovementioned method, some fields in the exported data might now begin with an apostrophe character ('). 

For more information, see Notes and limitations in data exports.

New REST API operation for deleting subscription

A REST API operation called "Delete a subscription by number" is now available. You can use this operation to delete a subscription of the specified subscription number.

New field on Subscription object to indicate the latest version

The isLatestVersion field is now available on the Subscription object to indicate whether the current subscription object is the latest version.

The Zuora API, data source, and data query have been enhanced to support this field.

Enhancement to lastBookingDate field on Subscription object

The lastBookingDate field is now made writable on the Subscription object. Previously, this was a read-only field.

The field is available as lastBookingDate in the data source, data query, and all the GET subscription REST and SOAP API. This field is available asBookingDate in the subscription creation UI (non-orders), the value from which is stored in the lastBookingDate field. Both the Booking Date and lastBookingDate fields map to the lastBookingDate field on the subscription object.

The field has the following limitations:

• This field is writable only when the subscription is newly created as a first version subscription.
• You can override the date value when creating a subscription through the Subscribe and Amend API or the subscription creation UI (non-Orders). Otherwise, the default value today is set per the user’s timezone.

For example, a new subscription version A1 is generated when the first subscription version A is modified. Version A’s lastBookingDate remains the same, while A1’s lastBookingDate will be either the Amendment.bookingDate or Order.orderDate.

New fields on Rate Plan and Rate Plan Charge objects

The following fields are now available on the Rate Plan object:

• Subscription Owner Id: the subscription owner ID of the subscription that contains the rate plan
• Invoice Owner Id: the invoice owner ID of the subscription that contains the rate plan

The following fields are now available on the Rate Plan Charge object:

• Subscription Id: the ID of the subscription that contains the rate plan charge
• Subscription Owner Id: the subscription owner ID of the subscription that contains the rate plan charge
• Invoice Owner Id: the invoice owner ID of the subscription that contains the rate plan charge

The Rate Plan data source, Rate Plan Charge data source, and SOAP API have been enhanced to support these fields.

Support for adding recurring prepayment charges to subscriptions at any time

You can now add recurring prepayment charges to subscriptions anytime. Previously, you could only add a recurring prepayment charge at the beginning of a validity period. This enhancement enables your customers to purchase recurring prepaid products whenever they want.

In order for a recurring prepayment charge to be able to be added to a subscription at any time, you must configure the following fields:

• Select Term Start Date from the Billing Day list.
• Select Align to Term Start from the Billing Period Alignment list.

If you use the “CRUD: Create a product rate plan charge” REST API or the “Create ()” SOAP API to create recurring prepayment charges, make sure to set the BillCycleType field to TermStartDate and the BillingPeriodAlignment field to AlignToTermStart in the request body.

Note the following behaviors of the recurring prepayment charges that are added in the middle of a validity period:

• The Start Date of the newly added fund is the Effective Date of the charge.
• There is no proration for the first partial billing period, which means the charge amount of the first partial billing period should be the same as that of a full billing period.
• Recurring prepayment charges cannot be added to a shrunk subscription term.

REST API enhancements for object key support

The following API operations have been enhanced to support managing billing documents, taxation items, and invoices by object numbers: 

• Email billing documents generated from a bill run
• Generate billing documents by account ID
• Create taxation items for a credit memo
• Update due dates for debit memos
• Create taxation items for a debit memo
• Update an invoice
• Email an invoice
• Upload a file for an invoice
• List all items of an invoice
• List all taxation items of an invoice item
• Reverse an invoice

Previously, these API operations only supported object IDs.

Enhancements to Sum function

The Sum function has been enhanced to support a list of numeric text inputs in HTML templates. 

Previously, this function only supported a list of numeric inputs.

Zuora Quotes 

The latest Zuora Quotes version is 10.8.

For the latest changes of Zuora Quotes, see Zuora Quotes version 10 release notes.

 Back to Table of Contents

Deprecation of Hosted Payment Method Pages 1.0

Hosted Payment Method Pages (HPM) 1.0 will be deprecated on July 15th, 2022 PDT. Starting from July 15th, payment pages and components implemented through HPM 1.0 will not work, such as HPM 1.0 pages, Checkout Pages, and CPQ components built on HPM 1.0. We will not provide support for any issues with HPM 1.0 and components or pages built on HPM 1.0. Payment Pages 2.0 are the replacement for HPM 1.0.

To get to know the version of a payment page in Zuora, navigate to Settings > Payments > Setup Hosted Pages, and the version information is available in the Page List section. A tooltip is also available next to the page name to indicate the version 1.0 page and the action to take.

If you have any questions about HPM 1.0, submit a request at Zuora Global Support.

Opayo Direct gateway integration available

A new gateway integration called Opayo Direct is now available in Zuora. It integrates with the Elavon Opayo Direct API to provide the following payment operations for credit card payment methods:

• Payment method validation
• Payment
• Payment void
• Referenced refund

The Opayo Direct gateway integration also supports 3D Secure 2.0 and stored credential transactions.

For more information, see Opayo Direct Gateway.

Support for processing MOTO payment transactions on BlueSnap

We have enhanced our BlueSnap gateway integration to support processing Mail Order Telephone Order (MOTO) payment transactions with Credit Card payment methods. You can pass the MOTO payment indicator to the gateway through either of the following methods:

• Select MOTO for the newly introduced setting called Transaction Order Source on the gateway setting page.
• Specify the newly supported TransactionOrderSource gateway option field through APIs or the client parameter of Payment Pages 2.0.

For more information, see Transaction Order Source configuration field and Supported gateway option fields for BlueSnap gateway integration.

REST API enhancements for payment run and refund management 

The following API operations have been enhanced to support retrieving and managing payment runs by using either the payment run number or payment run ID:

• Update a payment run
• Retrieve a payment run
• Delete a payment run
• Retrieve a payment run summary
• Retrieve payment run data

The following API operations have been enhanced to support retrieving and managing refunds by using either the refund number or refund id:

• Update a refund
• Retrieve a refund
• Delete a refund
• Cancel a refund

Previously, you could only specify payment runs or refunds in the above operations using the payment run ID or the refund ID.

Increased the maximum number of reason codes for the supported payment transaction types

We have increased the number of the reason codes you can define for a supported payment transaction type from 200 to 300. You can now create up to 300 reason codes for the following payment transaction types:

• Payment Refund
• Credit Balance Refund
• Invoice Item Adjustment
• Invoice Adjustment
• Credit Memo
• Debit Memo
• Credit Memo Refund

 Back to Table of Contents

Refresh or reset of testing configurations is deprecated

To prevent overwriting any testing configurations you have enabled, we no longer refresh or reset the following previously configured settings in Central Sandbox:

• Notifications (callout credentials-username/password)

Support for specifying unique constraints on custom fields

You can now create custom fields with unique constraints for custom objects to store unique values such as unique identifiers or names. Note that unique constraints apply only to filterable custom fields.

 Back to Table of Contents