Enhancements and fixes to Aria functionality for this release are described below.
Release Date
Stage Future Release Date
09-July-2024
30-July-2024
Aria supports the latest stable versions of the following Web browsers:
- Chrome 63
- Firefox 52
- Microsoft Edge
- Safari 11 on MacOS
1024 x 768 or higher
Application Features
Prompt Payment Discount For Rebilled Invoices (DEV-11231)
This feature ensures customers receive the correct discount for prompt payment even when an invoice is rebilled. Previously, the system either applied an incorrect discount or no discount at all. Now, the system removes the previous discount, then applies a new discount based on the invoice's due date.
Installment Terms Invoicing for NSOs—Phase 2 (DEV-11274)
Aria introduces further enhancements to the Installment Terms feature introduced in Release 58. These cover handling lump sum payments, mid-period cancellation of installments, and an additional use case for non-subscription offerings.
The new use cases and functionalities available in this release include the following (currently only available via APIs):
- Lump Sum Installment Term: This introduces a new attribute that allows for a single upfront payment, reducing the total installment amount spread over the period and minimizing the risk of uncollectible balances. There are 2 types of lump sums, ‘Proportionally Split (tax/charge)’ and ‘Tax’. The lump sum type determines the type of charges to be considered as a lump sum.
- Credit Memos Application: Apply credit memos to correct installment charges or to close remaining installment balances.
- Write-off for Uncollectible Balances: Write off any remaining uncollectible installment balances.
- Mid-period Cancellations: This allows for immediate or future cancellations of installment schedules. Upon cancellation, the invoice line will share the same due date as the invoice, triggering immediate collection attempts. If collection fails, the master plan instance that the item is mapped to will enter dunning.
- New Customer Purchases: Allows your new customers to purchase new NSOs with an installment term.
- Dunning for Electronic Payments: Dunning for electronic payments are available with this release.
- New Statement Status:
'Installment Due Paid': This indicates all due charges (both installment and non-installment) on the statement are paid. This status is accessible via the Aria UI (CCP and Aria Billing Cloud, under Accounts > [search for account] > Account Overview > Statements & Invoices > Statements [Status column]) and via Aria APIs.
Note: When an account statement includes an installment, Aria uses the installment due date to determine if the statement is late or if the statement status needs to be updated. If payment is collected on time, the statement status will be updated to ‘Installment Due Paid’. If the installment due is not paid, the statement is marked as ‘Late’ or ‘Late ok’.
- New Installment Schedule Statuses:
- Active: The installment schedule will be initiated starting upon invoice creation.
- Completed: The installment has been paid in full (through payoff or write-off).
- Cancelled: The Installment has been canceled mid-period and is due immediately.
Apple Pay Payment Method Now Available With WorldPay Smart Payments (DEV-11377)
Aria is excited to introduce Apple Pay as a digital payment method to our WorldPay Smart Payments integration. Tokenized payments are supported for the Visa® and Mastercard® card types.
To configure Apple Pay for WorldPay Smart Payments, navigate to the Apple Pay tab (Configuration > Payments > Payment Gateways/Collection Groups [WorldPay]). Download the Certificate Signing Request (.csr) file (Step 1). After downloading the .csr file, perform the following (Step 2):
- Visit the Apple Pay portal.
- Log into your merchant account.
- Attach the CSR file.
- Get the .cer format file.
After obtaining the .cer file, upload the file from the Apple Pay tab (Step 3) to complete the pre-requisite steps for making Apple Pay payments.
You can now contact Aria with your Apple Pay payload using existing Aria APIs as part of your WorldPay Smart Payments integration.
Dun Plan For Non-Electronic Payment Terms Using Cumulative Past Due Balance Should Be Considered for Account Balance Rather Than Statement Balance (DEV-11404)
A new parameter “Dun Plan For Non-Electronic Payment Terms Using Cumulative Past Due Balance” has been configured to consider the Account Balance instead of the Statement Balance as previously used for dunning determination.
Additionally, a checkbox titled Include all Subscriptions for Dunning has been added in the Configuration > Payments > Dunning Processes UI menu that, when enabled, considers all subscriptions under the attached Dunning Group for dunning when one subscription enters into dunning due to a late Payment Terms statement.
For the additional MPIs entering dunning, the MPI balance is assessed to calculate the dunning fees for each subscription under the Dunning Group and a new dunning comment is added, specifying the MPI that triggered the dunning process.
Worldline Phase 2—Smart Payments (DEV-11440)
With this release, Aria introduces Phase 2 of Worldline’s Smart Payments Integration, including the following features:
Soft Descriptor
This provides additional transaction details for your customers. This information appears on customer bank statements for credit/debit transactions. Soft descriptors can be entered at both the Payment Gateway and Collection Group levels (Collection Group takes precedence).
Navigate as follows to the soft descriptor field for Payments Gateways and Collection Groups (Configuration > Payments > [Payment Gateways/Collection Groups] > Field Options).
Soft descriptor support is currently implemented only for credit card transactions (pay methods 1 and 13) for the Visa and Mastercard card types. A maximum of 22 characters is allowed at the soft descriptor field; a field value beyond that limit will be truncated.
Cardholder-Initiated Transactions (CIT)/Merchant-Initiated Transactions (MIT)
When you use Worldline Smart Payments to process a Visa or Mastercard card transaction, you can now specify whether you are completing a cardholder- or merchant-initiated transaction and whether the card information is already stored in Aria.
Level 2/Level 3 Data
When applicable, Aria will send Level 2 and 3 data to Worldline for payment actions, resulting in savings on transaction fees. "Level 2" data refers to customer-specific affluence indicators, and "Level 3" data is specific to invoice line items. This applies only for credit card transactions (pay methods 1 and 13) for the Visa and Mastercard card types. A maximum of 99 invoice line items are supported and processed by Aria.
WorldPay Smart Payments now supports storage of shipping contact details in Aria by parsing this information from an Apple Pay-encrypted payload. Additionally, Aria has modified the implementation of SEPA Direct Debit Payments (Payment Method = 26) and Tokenized SEPA Direct Debit Payments (Payment Method = 37) so that, instead of a create_token request, now Aria will get a payment request. Transaction logging has been modified to support this change.
Ability to Filter API Logs By Account Number When Alternative Account Identifiers Specified in API Calls (DEV-11477)
This feature improves how Aria Billing Cloud logs API requests. Now, you can retrieve details for any Core API call in which an account was specified via <client_acct_id> or <user_id> by searching for an account number.
Note: Calls should pass basic input validations before being searched in this manner; you will be able to find create_acct_complete_m calls that create multiple accounts only by the first account number created; and, you will not be able to find create_acct_complete_m calls in which <do_write>="false."
Ability to Cancel Open Charges in Aria UI (DEV-11482)
This feature allows you to cancel open charges for a specific account related to a Proration No in the Aria UI. A new "Cancel Open Charges" icon next to the first charge listed for each account now displays on the Specified Account > Statements & Invoices > Open Charges tab for users with proper permissions. You can grant the new "Cancel Open Charges" permission for a user role on the Security > Account Access screen, under the Open Charges section, by specifying a CSR level and selecting On, for the Cancel Open Charges Viewable Link.
Learn more about Open Charges.
Legacy UI "Express Search"—Applying Functional Account Group-Based Role Restrictions on Express Account Searches (DEV-11501)
Functional account group-based role restrictions are now applied on users who perform Express Account Searches, honoring the functional account group settings as set on a user’s role.
Application Fixes
- When a supplemental plan instance is assigned after the creation of a master plan instance and has no bill lag day, the correct usage period is now used on the invoice. The usage period logic for invoice generation has been updated to calculate to one day before the next bill day, resolving a previous issue resulting in the incorrect usage period being used when creating an invoice. This update has been completed for all billing intervals (monthly, quarterly, weekly, daily). (TICKET-19034)
- The Copy Configuration function now omits total uses of coupons and total promotional registrations when copying from the source client to the destination client. (TICKET-19105)
- The Non-Provisioned Plans section from the Account > Plans UI tab now displays the correct plan instance details after parent plan instance cancellation. Previously, incorrect child plan instance details would display under Non-Provisioned Plans if any child plan of the cancelled parent plan was also in a cancelled status. (TICKET-19346)
- Aria now determines the Dunning status of Master Plan Instances (MPIs) based on past due statements. Previously, this Dunning check included the MPI's current Billing Group that, if changed, might have a zero balance and therefore take that MPI out of Dunning even if the customer had open charges for that MPI. (TICKET-19423)
- Aria now includes voided refunds of external payments when displaying payments eligible for refunds. Previously, Aria did not display these as payments eligible for refunds. (TICKET-19489)
API Features
Installment Terms Invoicing for NSOs—Phase 2 (APIs) (DEV-11274)
This release of Installment Terms Invoicing introduces the following new API:
Core/Account Transaction Creation
The following existing APIs have been enhanced for this release of Installment Terms Invoicing:
Inputs
| Field |
Definition |
| <master_plan_nso_list> array |
|
| <assign_installment_term> |
Y - Yes or N - No. If it's NULL then should be treated as No. Other values will treated as NULL when entered. |
| <client_installment_term_id> |
Specifies client installment id. If null, then it selects the installment default |
| OR |
|
| <installment_term_no> |
Installment no on product catalog. If null, then it selects installment default |
Outputs
| Field |
Definition |
| <invoice_info> |
Existing array |
| <invoice_items> |
Existing array |
| <installment_term_no> |
Aria assigned installment term no |
| <installment_no> |
Aria assigned installment schedule no |
Inputs
| Field |
Definition |
| <lump_sum_type> |
Lump sum type determines type of charges to be considered as a lump sum. Two types of lump sum are: proportionately split (tax/charge) or tax only. Allowable values are: P for proportionately split charge/tax; T - for purchase tax only. |
| <lump_sum_amount> |
Applicable only when lump sump type is proportionately split (lump_sum_type = P). A one-time amount that will reduce the total installment to be spread over the course of installment term. For example: a $1200 phone purchase with $200 lump sump will reduce the total installment amount to $1000, which will be spread monthly over 10 months installment term ($100 per month). Lump sum amount is mandatory when only when lump_sum_type is P (proportionately split charge/tax).
|
| <aligned_lump_sum> |
Applicable only for aligned installment (aligned_installment = Y). Determines when to notify customers of the lump sum. Allowable values are: 0 - Aligned with when an invoice is created; 1 - Aligned with the 1st installment
|
| <lump_sum_days> |
Applicable only for independent installment (aligned_installment = N). Determines how many days after a purchase or invoice date that a lump sum is charged and be notified to customers. For example: if 3 is passed, then 3 days after an invoice date, a lump sum will be charged. If 0 is passed, then 1st installment will start (and be notified to customers) on purchase date (invoice date).
|
| <lump_sum_days_until_due> |
Applicable only for independent installment. Determines how many days after customers are notified that a lump sum is due. For example: if 5 is passed, then 5 days after customers are notified, the lump sum will be due. If it's NULL, it will be treated as 0, and lump sum is due when it's notified to customers. |
Outputs
| Field |
Definition |
| <lump_sum_type> |
Lump sum type determines type of charges to be considered as a lump sum. Two types of lump sum are: proportionately split (tax/charge) or tax only. Allowable values are: P for proportionately split charge/tax; T - for purchase tax only. |
| <lump_sum_amount> |
Applicable only when lump sump type is proportionately split (lump_sum_type = P). A one-time amount that will reduce the total installment to be spread over the course of installment term. For example: a $1200 phone purchase with $200 lump sump will reduce the total installment amount to $1000, which will be spread monthly over 10 months installment term ($100 per month). Lump sum amount is mandatory when only when lump_sum_type is P (proportionately split charge/tax). |
| <aligned_lump_sum> |
Applicable only for aligned installment (aligned_installment = Y). Determines when to notify customers of the lump sum. Allowable values are: 0 - Aligned with when an invoice is created; 1 - Aligned with the 1st installment |
| <lump_sum_days> |
Applicable only for independent installment (aligned_installment = N). Determines how many days after a purchase or invoice date that a lump sum is charged and be notified to customers. For example: if 3 is passed, then 3 days after an invoice date, a lump sum will be charged. |
| <lump_sum_days_until_due> |
Applicable only for independent installment. Determines how many days after customers are notified that a lump sum is due. For example: if 5 is passed, then 5 days after customers are notified, the lump sum will be due. If it's NULL, it will be treated as 0, and lump sum is due when it's notified to customers. |
Outputs
| Field |
Definition |
| <out_invoices_list> |
Existing array |
| <invoice_items> |
Existing array |
| <installment_term_no> |
Aria-assigned installment term no |
| <installment_no> |
Aria-assigned installment schedule no |
Outputs
| Field |
Definition |
| <invoice_items> |
Existing array |
| <installment_term_no> |
Aria-assigned installment term no |
| <installment_no> |
Aria-assigned installment schedule no |
Input
| Field |
Definition |
| <include_all_installment_statuses> |
Include all installment statuses (Completed, Cancelled, Discontinued) not only Active in the search results. Allowable values are: TRUE or FALSE. If it's null, by default is set to FALSE |
Outputs
| Field |
Definition |
| <lump_sum_type> |
Lump sum type determines type of charges to be considered as a lump sum. 2 types of lump sum are: proportionately split (tax/charge) or tax only. Allowable values are: P - for proportionately split charge/tax; T - for purchase tax only. |
| <lump_sum_amount> |
Applicable only when lump sump type is proportionately split (lump_sum_type = P). A one-time amount that will reduce the total installment to be spread over the course of installment term. For example: a $1200 phone purchase with $200 lump sump will reduce the total installment amount to $1000, which will be spread monthly over 10 months installment term ($100 per month). Lump sum amount is mandatory when only when lump_sum_type is P (proportionately split charge/tax). |
| <aligned_lump_sum> |
Applicable only for aligned installment (aligned_installment = Y). Determines when to notify customers of the lump sum. Allowable values are: 0 - Aligned with when an invoice is created; 1 - Aligned with the 1st installment |
| <lump_sum_days> |
Applicable only for independent installment (aligned_installment = N). Determines how many days after a purchase or invoice date that a lump sum is charged and be notified to customers. For example: if 3 is passed, then 3 days after an invoice date, a lump sum will be charged. |
| <lump_sum_days_until_due> |
Applicable only for independent installment. Determines how many days after customers are notified that a lump sum is due. For example: if 5 is passed, then 5 days after customers are notified, the lump sum will be due. If it's NULL, it will be treated as 0, and lump sum is due when it's notified to customers. |
| <status_change_date> |
The date the installment status is updated |
| <comments> |
Additional comments regarding status updates |
Nominal Tax Rate Returned from Vertex For Selected APIs (DEV-11398)
Within your Vertex tax integration, Aria now captures the Nominal Tax Rate (same as the marginal tax rate), as shown below:
| Field |
Type |
Description |
| <tax_nominal_rate> |
double |
Nominal rate returned by the tax engine |
This value is applied to refund reversals and issuance of credit memos (Accounts > [search for an account] > Account Overview > Payments & Credits).
This is returned as an output parameter for the following Aria APIs:
Previously, only the Effective Rate from Vertex (whether a tax is effectively calculated on a transaction) was generated in API outputs. The Nominal Rate now returned focuses on the actual tax rate applicable to a transaction regardless of whether or not a physical tax value is due on the invoice.
This output field is for presentment purposes only; no calculations are generated from this field.
Learn more about Aria's Vertex integration from here.
This feature enhances the API call get_acct_plan_queued_changes_m. New output parameters provide more information about upcoming plan changes related to customer accounts:
| New Output Parameter |
Description |
| <current_rate_schedule_name> |
Name of the rate schedule currently associated with the plan instance. |
| <target_rate_schedule_name> |
Name of the rate schedule that will be associated with the plan instance after the queued plan change takes effect. |
| <anniversary_queue_ind> |
Indicator for anniversary type queue. |
| <processed_by_batch_ind> |
To indicate if the queue was executed via batch process. |
| <queue_type> |
Indicates the queue action.
| Value |
Description |
| 1 |
Plan Assignment |
| 2 |
Mandatory Child Plan Assignment |
| 3 |
Plan Replacement |
| 4 |
Plan Rollover |
| 5 |
Plan Cancellation |
| 6 |
Plan Update (units, rate schedule, status, etc) |
| 7 |
Plan Status Change |
|
| <execute_allowed> |
To indicate if the immediate execution is allowed for the queue. |
| <change_effective_date_allowed> |
To indicate if effective date change is allowed for the queue. |
| <delete_allowed> |
To indicate if queue can be deleted. |
| <update_date> |
The date when queue was last modified. |
This feature enhances the API call send_acct_email_m, allowing you to specify which contact's email you want to use via the new input field <contact_no>. You can obtain a <contact_no> either by calling get_acct_contacts_m or by viewing the Contacts tab of an account's Overview screen.
Specify How Refunded Payments Are Applied via issue_refund_to_acct_m (DEV-11523)
Aria has enhanced the API call issue_refund_to_acct_m to control how refunded payments are applied with the new input parameter <apply_refunded_payment_on_refund_trans>.
| New Input Field |
Description |
| <apply_refunded_payment_on_refund_trans> |
This parameter is added to control the existing behaviour of payment application to the refund transaction such that the refund amount should be applied to the specific payment against which the refund is created instead of FIFO application. This parameter is not honoured when refund with opening of paid lines is performed.
| Value |
Description |
| 0 |
Continue to work as per existing way of applying payment based on FIFO (default, except for open paid lines). |
| 1 |
Apply refund amount to the specific payment against which the refund is created. |
|
Note: This is not applicable when refunding to reopen closed line items or for partial refunds where the remaining amount is insufficient. In these cases, Aria returns errors. You can use the existing "No, open paid line items" option if you need to use the FIFO method or when the refunded payment balance is not sufficient.
API Fixes
- The get_promo_plan_set_details_m API has been updated to return only plans attached to the promo plan set in the API output response. Previously the API response incorrectly returned all existing plans even when no plans were selected. (TICKET-19409)
- Aria now bills for usage reported for an inactive plan instance when Aria activates the plan instance on a customer's billing anniversary. Previously, when you reported usage with a plan instance number of an inactive plan instance, the usage was not billed as expected. (TICKET-19441)
