Release 57
- Last updated
- Save as PDF
Overview
Enhancements and fixes to Aria functionality for this release are described below.
Release Date
Stage Future Release Date
14-May-2024
Production Release Date
6-June-2024
System Requirements
Supported Browsers
Aria supports the latest stable versions of the following Web browsers:
- Chrome 63
- Firefox 52
- Microsoft Edge
- Safari 11 on MacOS
Screen Resolution
1024 x 768 or higher
Release 57 Contents
- Application Features
- NSO Installment Terms Phase 1 (DEV-10927)
- Tax Calculation for Individual Usage Records (DEV-11229)
- Legacy UI "Express Search" Enhancements (DEV-11232)
- Adyen's Smart Payments Now Supports SEPA Payment Auto Rescue (DEV-11311)
- Avalara Allows Refunds Across Multiple Invoices (DEV-11358)
- Credit Card Type and Query Token Details Stored for Adyen Tokenized Cards (DEV-11378)
- Soft Descriptor, Tokenization and Fraud Sight WorldPay Smart Payment Enhancements (DEV-11382)
- Worldline Added to Smart Payments for Credit Cards and Tokenized Credit Cards (DEV-11383)
- Service Name Replacement String Does Not Honor Locale Translations (DEV-11412)
- Credit Note Replacement String Does Not Honor Locale Translations (DEV-11427)
- Application Fixes
- API Features
- NSO Installment Terms Phase 1—API Updates (DEV-10927)
- $0 Authorizations Disallowed For authorize_electronic_payment_m (DEV-11130)
- Tax Calculation for Individual Usage Records (DEV-11229)
- Enhancements to get_acct_writeoff_or_disputes_m, settle_dispute_hold_m, and create_writeoff_or_dispute_m APIs (DEV-11299)
- API Enhancements for Adyen Smart Payment Integration (DEV-11311)
- Enhanced get_acct_plan_balance_m API To Account For Payment Terms Due Date With Timestamp (DEV-11403)
- API issue_refund_to_acct_m No Longer Returns Uncommitted Rebill Details (DEV-11426)
- WSDL File Locations
Application Features
NSO Installment Terms Phase 1 (DEV-10927)
This feature allows you to sell high-priced Non-Subscription Offerings (NSOs) to your customers by letting them choose to pay in installments. NSO Installment Terms provides the following benefits:
- For your customers: Makes expensive NSO products more affordable by breaking the total cost into smaller payments.
- For you: Records the entire revenue from the NSO sale upfront.
You can define installment terms once, then map them to multiple NSOs in your product catalog. This prevents product catalog proliferation. You can then grant your customers the installment options mapped to the NSO they wish to purchase.
Note: Phase 1 of this feature is currently accessible only via API. See NSO Installment Terms Phase 1—API Updates (DEV-10927) API note below for more information.
Key Features
- Flexible Payment Options: Customers can choose to pay for high-priced NSO products in installments.
- Optional: Installment terms are optional, even if an NSO is configured with installments.
- Two Types of Installment Terms:
- Aligned with master plan instance: installment schedule (bill/notify dates, due dates) is aligned with the Master Plan Instance (MPI) associated with the NSO and is included in MPI anniversary statements. It will always follow the MPI anniversary dates and statements even if you adjust the MPI bill date.
- Independent: Installment schedule has its own bill/notify and due dates. Customers are notified of payments due via a new Email Template Class, Installment Due Reminder (IDR).
- Note: Aria Customer Support must enable a batch process for existing clients called Installment Schedule Due to use the IDR Email Template Class. The batch is enabled automatically for new clients.
- Enhanced Payment Collection and Payment Application: Payment collections exclude installments due in the future, and will honor your existing payment settings (e.g. First-Due-First-Out or First-In-First-Out).
- Discount Compatibility: This feature is compatible with coupons.
Click here to read about use cases showing the advantages of Installment Terms invoicing for you and your customers.
Tax Calculation for Individual Usage Records (DEV-11229)
This feature introduces the ability to tax usage at the individual usage record level when usage is rated at load time and you are using the Aria tax engine. This enhances the Usage Rating Per-Record feature introduced in Release 56. As with per-record usage rating, you can use this feature by setting the Taxation Level Indicator to "Individual" when configuring a usage-based service you are adding to a new or existing plan.
You can also report pre-calculated taxes for usage records, and a single invoice can support both pre-taxed usage records and not-yet-taxed usage records. See the API notes for DEV-11229 for details regarding API call support for tax calculation for individual usage records.
Notes:
- This feature is tailored to support low-volume usage records of approximately 100 records or less.
- If an invoice includes per-record usage taxes, you cannot perform a refund-reversal, create a credit memo, nor generate a rebill against it. Attempting any one of these, either via API or UI, results in Error 3117: "A Refund related Reversal/Credit Memo/Rebill cannot be performed since this invoice contains usage with either precalculated taxes, or taxes calculated at the individual record level."
Legacy UI "Express Search" Enhancements (DEV-11232)
Aria has added a new client parameter Configuration > Client Settings > Miscellaneous Settings > Enable Express Search that, when set to "True", enables a search algorithm that supports faster searches when using Accounts > Search in the Aria UI. This is especially useful if you have a large number of accounts, and allows you to search on the “Account User ID” or “Client Account ID” fields. Express Searches are also now logged to the Search History tab.
Adyen's Smart Payments Now Supports SEPA Payment Auto Rescue (DEV-11311)
Aria now supports "Auto Rescue" for SEPA payments. Auto Rescue is a payment recover feature that attempts to reprocess failed SEPA transactions up to three times depending on client settings.
The following two configuration settings have been introduced at the Payment Gateway and Collection Group levels (Configuration > Payments > Payment Gateways/Collection Groups > Field Options > Auto Rescue Options):
Field Name | Allowable Values | Tooltip |
---|---|---|
Auto Rescue Payment Recovery | On and Off (default) | Auto rescue is Adyen's payment recovery service. It will attempt to reprocess the transaction using their intelligence up to 2 times within the specified period for certain event codes. Refer to Adyen documentation for more details. Default is No. |
Maximum Rescue Days | 30 | Enter the maximum number of days that a failed SEPA/credit card transaction will be reattempted. For SEPA, Adyen only allows values between 1 and 42 days. For credit card payments, the allowed values are between 1 to 48 days (Aria recommends setting this value at 30 days). |
When the Auto Rescue Payment Recovery client setting is set to "On" and the SEPA payment fails, Adyen performs the auto rescuing of failed SEPA payments and notifies Aria whether the attempt has succeeded or failed.
Avalara Allows Refunds Across Multiple Invoices (DEV-11358)
For Avalara, Aria now allows refunds created across multiple invoices by processing the invoice number with the refund number in the Code field sent to the tax engine via the issue_refund_to_acct_m API and the UI (Accounts > [search for an account] > Payments and Credits > Refunds). This applies to the AvaTax and AvaREST transmission methods for the following actions: tax, post, void, and refund (for a reversal, credit memo, or write off).
Credit Card Type and Query Token Details Stored for Adyen Tokenized Cards (DEV-11378)
Adyen Smart Payments now displays the credit card type along with the query token details when storing a Tokenized Credit Card (pay method 13) at the Payment Methods tab (Accounts > [search for an account] > Account Overview > Payment Methods). This applies to the following card types: Visa, Mastercard, American Express, Discover, Diner’s Club, Japan Credit Bureau (JCB), and China UnionPay (CUP).
Soft Descriptor, Tokenization and Fraud Sight WorldPay Smart Payment Enhancements (DEV-11382)
Soft Descriptor
Aria has implemented soft descriptors to set the description that will appear on a customer’s bank statement for credit/debit transactions. This applies to Credit Card, Tokenized Credit Card, ACH and SEPA payments. This can be added at the Payment Gateway level (Configuration > Payments > Payment Gateways/Collection Groups > Field Options tab) and the Collection Group level (Configuration > Payments > Payment Gateways/Collection Groups > Advanced Options tab) level.
Aria truncates the original soft descriptor to the maximum allowable characters before sending it to WorldPay, in accordance with the pay methods in the following table:
Pay Method | Maximum Amount of Allowable Characters |
---|---|
Credit Card, Tokenized Credit Card | 22 |
ACH, SEPA, Tokenized SEPA | 25 |
Tokenization
For pay method 37 (Tokenized Direct Debit), Aria will store the IBAN suffix (last four digits of the account number) when creating a token for this pay method. Aria will also store the generated mandate_id value when creating a token. Both the IBAN suffix and the mandate_id values will be displayed on the Payment Methods list (Accounts > [search for an account] > Account Overview > Payment Methods).
Fraud Sight
Aria has also implemented WorldPay’s Fraud Sight feature to integrate with WorldPay’s credit card fraud protections. Aria receives the
Worldline Added to Smart Payments for Credit Cards and Tokenized Credit Cards (DEV-11383)
With this release, Aria has now integrated the Worldline payment gateway as part of Smart Payments for the Credit Card and Tokenized Credit Card pay methods. This initial phase of integration supports the following actions:
- Authorization
- Capture
- Create Token
- Query Token
Transactions can be reversed using the Aria UI or by the reverse_authorize_electronic_payment_m with the authorization number of the authorized transaction. Tokens can be deleted either by the remove_acct_payment_method_m API or by deleting a tokenized payment method.
Service Name Replacement String Does Not Honor Locale Translations (DEV-11412)
The displayed Service Names of the service charge items associated to an invoice now correctly display in the language defined by the Statement Template's assigned locale when <insertItemSimpleLabel> is used.
Credit Note Replacement String Does Not Honor Locale Translations (DEV-11427)
To ensure plan name is displayed in the correct language on a Credit Note when <insertReversedItemOrgPlanName> is used, the Credit Note template now honors locale translations from the locale number provided in the Credit Note Template. If a locale number is not provided at the Credit Note template level, then the plan name is returned per the Client Level locale settings, which is set to English by default.
Application Fixes
- Mixed-case usernames (Name ID) are now converted into fully lower-case usernames and matched with Aria user credentials to facilitate Aria’s SSO login process. This enables you to use existing mixed-case Name IDs to login to Aria via SSO. (TICKET-19321)
- Aria now correctly generates prorated recurring charges during plan assignment via UI for given <alt_bill_day> and <retroactive_start_date> inputs when the <invoicing_option> is set to 'Prorated Invoicing'. This also applies to combined invoice generation that includes a prorated billing period with an <alt_bill_day> input during plan assignment via UI. Previously, the <alt_bill_day> input was not being honored during invoice generation when plans were assigned via UI which led to the invoice not being prorated. (TICKET-19332)
- The Aria UI has been modified to retrieve the correct Currency Format Mask defined in the system for the currency being used. Previously, the default currency format was used leading to the incorrect display of “,” and “.” in the EUR currency. In tandem, the code that handles the Refund reversal range validation has also been updated to honor the system-defined Currency Format Mask. Previously an error occurred during the Refund with Reversal process that displayed “Amount entered is not within allowable range” even when the amount supplied was valid. (TICKET-19387)
API Features
NSO Installment Terms Phase 1—API Updates (DEV-10927)
The following APIs have been added and/or enhanced for this feature:
New Admintools APIs
- create_installment_term_m (New)—Creates installment terms to allow multiple payments for a Non-Subscription Offering. Once created, the terms must be mapped to a product when creating an order.
- get_installment_terms_m (New)—Gets the details of the specified installment term. If no installment term is specified, it returns the data for all installment terms.
Updated Admintools APIs
New Inputs: create_inventory_item_m
Field Name | Field Type | Max Length | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
<installment_terms> | Array | A list of installment terms can be mapped to an inventory item | |||||||
<installment_term_no> |
Int | 100 | Installment no | ||||||
OR |
|||||||||
<client_installment_term_id> |
String | 100 | Client installment term id | ||||||
<is_default> |
Boolean | 1 |
Mandatory to pass a default installment term.
Allowable Values
|
New Outputs: get_inventory_items_m
Field Name | Field Type | Description |
---|---|---|
<installment_terms> (Array) | Installment term details assigned to an account. | |
<installment_term_no> |
long | Aria-assigned unique identifier for client installment term. |
<client_installment_term_id> |
string | Specified client installment term id. |
<installment_term_name> |
string | Specifies installment term name. |
New Inputs: update_inventory_item_m
Field Name | Field Type | Description | ||||||
---|---|---|---|---|---|---|---|---|
<installment_terms> (Array) | A list of installment terms can be mapped to an inventory item. | |||||||
<installment_term_no> |
long | Installment no. | ||||||
OR |
||||||||
<client_installment_term_id> |
string | Client installment ID. | ||||||
<is_default> |
int |
The value of 1 is defaulted for the first installment term denoting it is the default. For subsequent installment terms, the default is set to 0. Alternate boolean values are accepted. Allowable Values
|
New Core APIs
get_acct_installment_m (New)—Return the installment term details for all installment plans on an account.
Updated Core APIs
New Inputs: create_order_m
(Add to existing <order_line_items> array)
Field Name | Field Type | Max Length | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
<assign_installment_term> | string |
Allowable Values
Note: Other values will be treated as NULL when entered.
|
|||||||
<client_installment_term_id> | string | Specifies client installment id. If null, then it selects the installment default. | |||||||
OR | |||||||||
<installment_term_no> | string | Installment no on product catalog. If null, then it selects the installment default. |
New Outputs: get_order_items_m
Field Name | Field Type | Description | ||||||||
---|---|---|---|---|---|---|---|---|---|---|
<installment_terms> (Array) | Summary of installment terms associated with items in an order. | |||||||||
<client_installment_term_id> |
string | Specifies client installment term id. | ||||||||
<installment_term_name> |
string | Specifies installment term name. | ||||||||
<installment_description> |
string | Installment term description. | ||||||||
<aligned_installment> |
string |
Aligned installment schedule with existing master plan instance.
Allowable Values
|
||||||||
<term_type> |
string |
Allowable Values
|
||||||||
<term_length> |
int |
Installment term length. For example if interval type is M (Monthly), if users enter 36 then, installment period is 36 months.
|
||||||||
<interval> |
int |
Installment interval, works jointly with terms type. For example: 2 on interval and months in terms type mean installment is due every 2 months. If defined, must be less than terms length.
|
||||||||
<days_to_start> |
int |
Applicable only when aligned_installment is No (N)—Its own installment schedule and due dates. Determines how many days after a purchase or subscription date that the first installment will start.
For example: if 5 is passed, then 5 days after a purchase date 1st installment will start. If 0 is passed, then 1st installment will start on purchase date. |
New Inputs: record_external_payment_m
Field Name | Field Type | Max Length | Description |
---|---|---|---|
<payment_application_method> | int | 1 |
New Allowable Value: 4—LIFO (applicable for installment ONLY)
|
New Error Codes
Code | Description | Affected API |
---|---|---|
32001 | Installment term no does not exist. | create_order_m |
32002 | <installment_number> cannot be updated to a non-default. Assign another installment term number as the new default installment term. | update_inventory_item_m |
32003 | <installment_number> cannot be deleted. Assign another installment term number as the new default installment term. | update_inventory_item_m |
32004 | Client installment term id does not exist. | create_order_m |
32005 | Assign one installment term as a default using the input parameter is_default. | create_inventory_item_m, update_inventory_item_m |
32006 | Inputs conflict: assign_installment_term input conflicts with client installment term id or installment term no. | create_order_m |
$0 Authorizations Disallowed For authorize_electronic_payment_m (DEV-11130)
Aria has updated the API call authorize_electronic_payment_m to disallow $0 authorizations. Previously, this API call only rejected negative input amounts. Now, it returns an error when the input amount is less than or equal to 0. Instead, you should use validate_payment_information_m when you require a $0 authorization.
Tax Calculation for Individual Usage Records (DEV-11229)
This feature enhances several API calls to support taxation for the Per-Record Usage Rating feature introduced in Release 56 for usage records rated at load time.
Note: Calling the APIs issue_refund_to_acct_m (to create a refund-reversal), create_cm_m (to create an invoice based credit memo), or gen_rb_m (to generate a rebill)—and specifying an invoice that includes per-record taxes for usage—will result in Error 3117: "A Refund related Reversal/Credit Memo/Rebill cannot be performed since this invoice contains usage with either precalculated taxes, or taxes calculated at the individual record level."
New Inputs
APIs | New Input Field | Description | |||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Notes:
|
<usage_record_taxation_level_ind> |
Indicates whether the usage taxation to be done at individual record level or aggregated records level. Allowable Values
|
|||||||||||||
Notes:
|
<precalc_tax_inclusive> |
Determines whether or not the usage amt includes the <precalc_tax_amt>. Setting this value to "true" means that the <usage_amt> includes the <pretax_amt>. Allowable Values
|
|||||||||||||
<precalc_tax_records> (array) |
Precalculated tax records specific to usage records. |
||||||||||||||
|
Precalculated tax amount. |
||||||||||||||
|
Preclaculated tax rate. |
||||||||||||||
|
Precalculated taxable amount. |
||||||||||||||
|
Precalculated tax jurisdiction name. |
||||||||||||||
|
Precalculated tax authority level. Allowable Values
|
||||||||||||||
|
Precalculated tax type id. |
||||||||||||||
|
Precalculated tax type description. |
||||||||||||||
|
Precalculated tax category. |
||||||||||||||
|
Precalculated tax summary. |
New Outputs
APIs | New Output Field | Description | |||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
<usage_record_taxation_level_ind> |
Indicates whether the usage taxation to be done at individual record level or aggregated records level. Allowable Values
|
|||||||||||||
<usage_record_tax_details> (array) |
Array of usage tax details. |
||||||||||||||
|
Aria-assigned usage record identifier. |
||||||||||||||
|
Line number associated with each tax detail record. |
||||||||||||||
|
Amount of tax applied for the given tax type. |
||||||||||||||
|
Rate at which tax is calculated for the tax type used by the tax engine. |
||||||||||||||
|
Taxable amount of the tax type returned by the tax engine. |
||||||||||||||
|
Jurisdiction name returned by the tax engine. |
||||||||||||||
|
Tax jurisdiction code. Allowable Values
|
||||||||||||||
<tax_type_id> |
Identifier of the tax type returned by the tax engine. |
||||||||||||||
<tax_type_desc> |
Description of the tax type returned by the tax engine. |
||||||||||||||
<tax_category> |
Category of the tax type returned by the tax engine. |
||||||||||||||
<tax_summary> |
Summary text returned by the tax engine. |
||||||||||||||
<is_excluded> |
Specifies whether or not this tax record is included for invoicing. Allowable Values
|
||||||||||||||
get_unbilled_usage_summary_m |
<unbilled_usage_rec> (array)
|
Flag to differentiate Client-calculated and Aria-calculated taxes. Allowable Values
|
|||||||||||||
<unbilled_usage_rec> (array)
|
This flag denotes if a rate is inclusive of the taxes. Allowable Values
|
||||||||||||||
get_usage_history_m |
<unbilled_usage_recs> (array)
|
Flag to differentiate Client-calculated and Aria-calculated taxes. Allowable Values
|
|||||||||||||
<unbilled_usage_recs> (array)
|
This flag denotes if a rate is inclusive of the taxes. Allowable Values
|
||||||||||||||
get_usage_history_information_m |
<usage_history_information> (array)
|
Flag to differentiate Client calculated and Aria calculated taxes. Allowable Values
|
|||||||||||||
<usage_history_information> (array)
|
This flag denotes if a rate is inclusive of the taxes. Value of 1 means tax inclusive rates and a value of 0 (default) means tax exclusive rates. Allowable Values
|
||||||||||||||
<usage_history_information> (array)
|
Array of usage tax details. |
||||||||||||||
|
Line number associated with each tax detail record. |
||||||||||||||
|
Amount of tax applied for the given tax type. |
||||||||||||||
|
Rate at which tax is calculated for the tax type used by the tax engine. |
||||||||||||||
|
Taxable amount of the tax type returned by the tax engine. |
||||||||||||||
|
Jurisdiction name returned by the tax engine. |
||||||||||||||
|
Tax jurisdiction code. Allowable Values
|
||||||||||||||
|
Identifier of the tax type returned by the tax engine. | ||||||||||||||
|
Description of the tax type returned by the tax engine. | ||||||||||||||
|
Category of the tax type returned by the tax engine. | ||||||||||||||
|
Summary text returned by the tax engine. | ||||||||||||||
|
Specifies whether or not this tax record is included for invoicing. Allowable Values
|
Enhancements to get_acct_writeoff_or_disputes_m, settle_dispute_hold_m, and create_writeoff_or_dispute_m APIs (DEV-11299)
Aria updated the API calls get_acct_writeoff_or_disputes_m, settle_dispute_hold_m, and create_writeoff_or_displute_m with the following changes:
API | Field Name | Updates |
---|---|---|
|
<is_voided> |
Output field added. You can consider this field a replacement for the field <can_unsettle> (see below). |
|
<can_unsettle> |
Output field deprecated. |
|
<invoice_amt> |
Output field now shows the total of the invoice associated with a writeoff. Previously, this total only included the total charge of items associated with a writeoff and did not include the other line items on the invoice. |
API Enhancements for Adyen Smart Payment Integration (DEV-11311)
The following API has been added and an existing Aria API has been enhanced in support of Adyen's Smart Payments integration.
cancel_payment_retry_m (Added)
Use this API to cancel the payment retry.
get_acct_payment_history_m (Enhanced)
Additional fields added to support this functionality follow:
Input
Field Name | Field Type | Max Length | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
<filter_retry_payments> |
long |
3 |
This param is used to filter payments that were reattempted. If filter_retry_payments value is 1, reattempted payment will be retrieved. If 0 or null (default), all payments will be retrieved. Allowable Values
|
Output
Field Name | Field Type | Description | ||||||
---|---|---|---|---|---|---|---|---|
<payment_retry_status> |
long |
Returns the payment's retry status. Allowable Values
|
New Error Codes
In addition, the following error codes are now returned:
Code | Description | Affected API |
---|---|---|
1016 | Invalid input. Allowed values are 0 and 1 (for <filter_retry_payments>). | get_acct_payment_history_m |
2010 | The payment ID is not valid or is not associated with account number. | get_acct_payment_history_m |
33001 | Cancellation failed. This transaction is ineligible for an automated payment recovery process (payment record must be eligible with rescue status = 1). | cancel_payment_retry_m |
33002 | Could not cancel the automated payment recovery process for this transaction. | cancel_payment_retry_m |
Enhanced get_acct_plan_balance_m API To Account For Payment Terms Due Date With Timestamp (DEV-11403)
The get_acct_plan_balance_m API has been enhanced to remain consistent with the due date logic implemented for ‘Payment Terms’ MPI dunning.
A new input parameter <current_balance_and_transfer_calc> for the get_acct_plan_balance_m API was introduced to implement this change. The <current_balance_and_transfer_calc> input parameter has the allowable values of 0 (Default. The current balance due amount and current balance transfer unpaid are considered due from the start of the due date independent of statement level payment type.) and 1 (The current balance due amount and current balance transfer unpaid are considered due depending on the statement level payment type. If statement payment type is “Payment Terms”, these are due at the end of the due date (i.e. next day of due date). If the statement payment type is not “Payment Terms”, these are due at the start of the due date.)
The <current_balance_due> and <current_balance_transfer_unpaid> output responses for get_acct_plan_balance_m now considers the statement balance amount as due only on the next day of ‘statement due date’ when the new input parameter is set to 1.
New Input parameter for get_acct_plan_balance_m API:
Input
Field Name |
Field Type |
Max Length |
Description |
||||||
---|---|---|---|---|---|---|---|---|---|
<filter_retry_payments> |
long |
3 |
This param is used to filter payments that were reattempted. If filter_retry_payments value is 1, reattempted payment will be retrieved. If 0 or null (default), all payments will be retrieved. Allowable Values
|
API issue_refund_to_acct_m No Longer Returns Uncommitted Rebill Details (DEV-11426)
The issue_refund_to_acct_m API call no longer returns values for the fields <rebilled_invoice_no> and <reversing_date> during a refund-rebill operation when <do_write> is "false." A value for <reversing_date> is also not returned when <do_write> is “true” for a refund-rebill (because there was no reversal).
WSDL File Locations
Stage Current
Stage Future
Production
Object Query WSDL Files
Stage Current
Stage Future
Production