For non-English speakers, the country field in payment pages should be in Alphabetical order.
When passing in a locale to the payment pages that's not in English, Zuora should display the country drop down in alphabetical order. Currently it doesn't which leads to poor customer experience.
Resultant non-sorted country drop down list
Customers who speak French, German etc shouldn't have to have in their heads what the english name is, then translate to the german name for example when choosing their country from the drop down. E.g. Germany begins with G in English but D (Deutschland) in German, therefore Deutschland should appear in the 'D' part of the drop down. Likewise Spanish customers should be looking at the 'E' part of the drop down, not having to scroll much further down for 'S'.
We need to be notified when a customer's email address is incorrect or no longer valid in order to take action and proactively reach out for a new contact.
Currently the Zuora refund ID is sent to Cybersource but when a payment is made its the Zuora payment number, not ID. It would be great to be more consistent and have both be the Zuora payment/refund number. This makes reconcillation easier for customers.
Having Tax mode at the rate plan charge prohibits using the same Charge for Mexico and the US with just different currencies. Causes us to have to setup a "duplicate to have one tax inclusive (Mexico VAT) and one tax exclusive (Canada/ US Taxes.)
One of my customers needs to have the state/province ISO codes returned instead of or along with the state names when querying for accounts or contacts. Can we please add this feature?
Receipts for customers need to include more information, such as the invoice number(s) the payments were applied to and the method of payment used. Even a PDF copy for the customer would be benenficial too, similar to the PDF copies of invoices that are included in the invoice emails.
In Australia/NZ we need the ability to turn off the automatic generation of updated invoice PDF's after the processing of Payments, Refunds, Amendments etc. The first PDF needs to be generated and maintained as the original record for audit and Customer enquiry purposes.
At the moment there is a Tenant setting that can be set to not generate PDF's at all, however this is not sufficient as we need to generate the first and no more
Currently it is only possible to run a single BillRunPreview call at a time. You have to wait for the current request to complete before you can submit another call. There should be a queuing ability inside Zuora instead of customers needing to handle the queuing.
Bill Run will pick up both, so eventually invoice amount will be 0 amounts. Unless applying Invoice Item Adjustment, 2 line items will be remaining forever with 0 amounts.
In case of cancelling with backdated cancellation date (bill in advance), it is required to refund the amount already paid by end users. If I do cancellation, subscriptions will be cancelled. And next Bill Run calculates amounts that needs to be refunded (amounts of over payment), then creates negative amount invoices.
Refund function can refund the amount by specifying invoices that are already paid. In case of this, specified invoice will be treated as “not paid”
Therefore, there will be 2 invoices. One invoices ( with positive amount) that is created by refund. And another invoice (with negative amount) that is created by bill run after cancellations.
As for the operational point of view, both positive and negative amount of invoices are not needed. At the same time, account balance will be 0 amounts. However, both invoices will be remaining of you do not do anything.
Meaning, it needs to set both invoices 0 amounts by Invoice Item Adjustment functions.
Currently transactions/invoices and transactions/payments REST API allow only Account as a filter. Those respond all records of invoices and payments in an account.
We need more filters in the request, at least Invoice Date or Payment Date for the filter in reqest to narrow down the response.
Many European merchants require the ability to produce invoice and credit numbering for specific document types, geographical regions, channels or business units.
These number sequences should be definable by the user including length, prefix, starting number, value, etc.
Currently, the InvoiceItem table on the invoice template cannot display the name of the related charge that a discount charge has been applied to, so it can be confusing when trying to understand which discount line item is related to which charge line item. It would be great if the invoice template could show the total discount amount for each invoice item (similar to how it shows the total tax related to each invoice item in InvoiceItem.TaxAmount). That would match how the Zuora UI displays discounts - see below.
Zuora really needs customer account statements. These should be able to be pulled at any time without running an invoice. It would combine charges, payment, and balance information in one place. Customers often request at least a year's history. The workaround to use a custom invoice is clunky and doesn't really cut it. Every other accounting system that I have used has this capability.
Currently, the InvoiceItem table on the invoice template cannot display any custom fields from the Rate Plan or Rate Plan Charge objects (without grouping on them), and can only display the following fields from the Product Catalog:
It would be great if the invoice template could display and group on custom fields from the Product, ProductRatePlan, ProductRatePlanCharge, RatePlan, or RatePlanCharge objects in the InvoiceItem table. Customers often store attributes such as product family, device names, service classes, etc in custom fields on those objects, and usually want to print those values on the invoice.
We have been doing a lot of work on payment failures recently and have found a big restriction with how the sandbox environment is configured to run the reconciliation report between GoCardless and Zuora once a day (14:30 BST). We think it would be beneficial to be able to trigger this job manually (in Sandbox environments only).
To assist with responsive page design on checkout pages it would be ideal if the Payment Pages iFrame was more responsive.
At present the size of the iframe is set to fit the avaliable space when the the iframe is loaded. If a customer then changes the window size (ie, rotates iPad, resizes browser) then the size of the iframe does not change, this can lead to poor layout of the checkout pages and a bad experience for the customer.