Release 56

Remove Contract From Deleted Queued Master Plan Instance When Contract Only Contains That Master Plan Instance (DEV-11094)

Aria now automatically cancels Multi-Plan Contracts when the only plan in the contract is a deleted queued plan instance. The contract, which no longer has any plans attached to it, is displayed as ‘Cancelled’ on the Plans > Contracts screen. This covers both deleting the queued plan assignment from the Plans > Future Plan Changes tab in the Aria UI and deleting via the edit_acct_plan_queued_changes_m API.

Usage Rating Per Usage Record (DEV-11230)

This new feature allows you to specify that Aria should rate usage per the number of units recorded per record. Because Aria rates the usage units recorded via the usage record at load time, you can offer your customers a more immediate snapshot of their current usage charges and associated taxes, and you are not bound by customers' billing cycle dates. This rating method honors all specified pricing rules for the usage-based service (Standard, Volume Discount, Flat Rate Per Tier) but overrides your existing usage accumulation and pooling configurations.

You can specify this rating mechanism when configuring a usage service in a plan, or when recording usage.

• Automatically Rate Un-rated Usage Records at Load Time—While you can set this parameter to "False" in your Aria instance, you can override it when configuring a usage service during plan creation—or recording usage—as "rate at the individual level," either via the UI or an API call. In this case, it will be rated at load time.
• Backdate Usage Rating—Aria will rate usage via a backdated individual usage record based on pricing associated with the service/usage type combination on the <plan_instance_no> (when specified) for the <usage_date> specified if pricing history is available.
• Reject Usage When Usage Type Not On Plan—Related to Backdate Usage Rating (above), if Aria does not find historical pricing related to a plan instance/service combination for the given usage type, it reverts to "current date" pricing if the usage type is valid for an active service on the specified account.

See the Rate Usage Per-Record article, and the below writeup, "New API Fields Supporting Usage Rating Per Usage Record," for more details.

Invoice Total Value Modified to Calculate Subtotal + Tax After Including Service Credits (DEV-11260)

Statement logic has been enhanced to add a new replacement string in which the Invoice Total calculation will return the sum of the Subtotal + Tax after the service credits for the invoice are applied. 

Open Charges for MPIs and SPIs Enhanced for Self-Pay Plans (DEV-11287)

Aria has improved the invoicing process of open charges for master plan instances (MPIs) along with supplemental plan instances (SPIs) in cases where a plan generates an open charge prior to its anniversary and is then canceled. This applies to self-pay plans. If the canceled MPI is the final one in a billing group, Aria generates a prorated invoice that includes open charges for both the MPI and any supplemental plans. If there are other active MPIs in the same billing group, orphaned charges will now be billed on the anniversary date for that billing group. This applies to future open charges only.

Auto-renew Contract With A Completion Date On The 28th Shifts The End Date In February And All Following Months (DEV-11291)

Aria has implemented an ‘Align to bill day' feature for Auto-Renewal contracts which start on the bill day. This ensures that the 'end date’ of renewed contracts is one day prior to the bill day and the contract is processed within the billing interval instead of spanning to the next billing cycle. This feature is applicable when the client parameter Contract End Date Behavior When Starting On Bill Day At End Of Month is set to 'Align to bill day'.

Taxpayer ID Is Now Purged By Account Anonymization (DEV-11301)

The Account field ‘Taxpayer ID' is now masked when an account is anonymized via Account Overview > Account Security > Anonymize Account in the Aria UI. When an account is anonymized, the 'Taxpayer ID' field displays as 'X’.

Empty Account Updater Files No Longer Sent to Chase Paymentech (DEV-11308)

The Account Updater has been enhanced in this release so that empty Account Updater files are no longer sent to Chase Paymentech. One condition for this was created when the required Division Code was neither configured nor matched to the account’s country. To configure Account Updater fields, navigate to Configuration > Payments > Payment Gateways > Field Options.

Adyen Smart Payments Now Supports Dynamic Soft Descriptor for SEPA (DEV-11310)

The dynamic soft descriptor field is now supported for SEPA payments within Adyen Smart Payments (via Configuration > Payments > Payment Gateways/Collection Groups > Field Options). You need to configure the soft descriptor field (for Payment Gateways and Collection Groups) using <Invoice_ID> and <Sequential_Statement_ID>. These inputs will be replaced with actual values at the time of the payment attempt, which will be recorded in the Adyen payment portal. As part of this enhancement, the Soft Descriptor field length has been increased to 255 characters.

The Dynamic soft descriptor is supported for the following payment methods:

• Credit Card (pay method=1)
• Tokenized Credit Card (pay method =13)
• ACH (pay method =2)
• Tokenized ACH (pay method =48)
• Direct Debit (pay method =26)
• Tokenized Direct Debit (pay method =37)
• Tokenized Klarna (pay method =43)
• Tokenized Apple pay (pay method =47)

Commodity Code Type Added For Vertex Tax Integration (DEV-11319)

The Commodity Code Type field has been added as part of your Vertex tax integration with this release.

In accordance with Vertex's requirements, Aria now passes the following fields in order to utilize the Commodity Code feature:

Both the Commodity Code and Commodity Code Type must be passed to utilize the Commodity Code feature.

Vertex allows the following Commodity Code types: UNSPSC, NCM, Service, and HSN. If you use the Commodity Code Type field, contact Vertex about field values based on your use case or supported products or services (code is unique for international trading purposes).

Learn more about Aria's integration with Vertex from here.

Recurring Payment and $1 Authorization Support for WorldPay Smart Payments (DEV-11321)

WorldPay’s Smart Payments integration now includes recurring processing model support (via the <rpm_Ind> field for the authorize_electronic_payment_m API) for Cardholder-Initiated Transactions and Merchant-Initiated Transactions. Valid values are:

• 0 (CIT – Credentials on File)
• 1 (CIT – New)
• 2 (MIT – Recurring)
• 3 (MIT – Credentials on File)

This applies to the Credit Card (#1) and Tokenized Credit Card (#13) pay methods.

Also, $1 authorization reversals have been enabled for WorldPay Smart Payments with this release. Initially, an authorization is performed for the incoming auth request. When an authorization is successful and the auto-reverse is enabled within the authorization request, a reversal request is built using the reference data from the original request and response.

The following client parameter must be set to True to enable an authorization request:

Please consult your Aria representative to enable this client parameter.

WorldPay Smart Payments Enhancements for SEPA Direct Debit (DEV-11354)

Aria has built additional functionality into WorldPay's Smart Payments integration with this release, including the following features:

• Aria introduces the WorldPay Query Token, which can be used for tokenized SEPA payments by passing in the bill_agreement_id as the token (referencing a back-end table in Aria).
• SEPA Direct Debit payments are now supported for WorldPay (Pay Method 26). Aria first performs an authorization transaction and then a capture transaction when receiving a Direct Debit payment request. The payment is authorized first, then captured, and finally settled by the customer's bank once the fund transfer is complete.
• SEPA Direct Debit Create Token functionality is now supported for WorldPay. This has been implemented along with Tokenized SEPA Direct Debit payments (Pay Method 37).
• SEPA Direct Debit Payment full and partial refunds are now supported for Pay Methods 26 and 37.

Transaction logging has also been implemented for the following:

• SEPA Direct Debit Payments
• SEPA Direct Debit Create Token and Tokenized SEPA Direct Debit Payments
• SEPA Direct Debit Refunds (must be in a settled status)

"Rebill" For "Refund Reversal Action" Now Supports "Full Refundable Amount" (DEV-11373)

This feature introduces support for choosing "Full refundable amount" when initiating an invoice-based refund when you have set the value of the Payment Settings parameter "Refund Reversal Action" to "Rebill." Previously in this scenario, Aria required that you choose "Other amount" and specify the amount paid against each line item on the invoice. In addition, Aria now displays tax line items for these fully reversed charges onscreen as expected.

‘Offset Months' And ‘Auto Offset Months Option’ Honored When Supplemental Plan Is Assigned With <assignment_directive> = 3 And <force_master_bill_date_reset> = 1 (DEV-11081)

Aria now honors the ‘Offset Months' and ‘Auto Offset Months Option’ values when a Supplemental Plan is assigned with <assignment_directive> = 3 (Immediate assignment with no proration) and <force_master_bill_date_reset> = 1 (Do not reset master plan billing dates) via update_acct_plan_multi_m API. This ensures the <next_bill_date> and the <last_bill_thru_date> of the newly assigned Supplemental Plan instance are calculated per the given 'Offset Months’ value.

New API Fields and Validations Supporting Usage Rating Per Usage Record (DEV-11230)

To support the new feature specifying that usage should be rated per record (see writeup above in Application Features), Aria has updated several API calls related to creating or updating plans, and reporting or retrieving usage. These changes include new fields, new validations, and a field that is no longer supported.

• If you attempt to record "negative usage" via record_usage_m or bulk_record_usage_m API, then Aria will return Error 14401 "Negative Usage Records, unless pre-rated, are not allowed when the Rating Model rates usage on a 'per record' basis."
• If you attempt to enable Usage Pooling via the following API calls, then Aria will return Error 14402 "Usage Pooling is not allowed when the Rating Model rates usage on a 'per record' basis."
  • record_usage_m
  • bulk_record_usage_m
  • create_acct_complete_m
  • update_acct_complete_m
  • assign_acct_plan_m
  • update_acct_plan_m
  • replace_acct_plan_m
  • update_acct_plan_multi_m
• If you attempt to enable Usage Pooling in the following API calls, Error 14137 "To permit usage pooling on plans the invoice settings parameter 'Allow MPI Level Usage Pooling' needs enabling."
  • create_acct_complete_m
  • update_acct_complete_m
  • assign_acct_plan_m
  • update_acct_plan_m
  • replace_acct_plan_m
  • update_acct_plan_multi_m

The field <usage_rating_timing> is no longer supported in these API calls: 

• create_usage_type_m
• update_usage_type_m
• get_usage_type_details_m
• get_usage_types_m

Taxpayer ID Is Now Purged By Account Anonymization (DEV-11301)

The Account field ‘Taxpayer ID' is now masked when an account is anonymized via the delete_acct_data_m API. When an account is anonymized, the 'Taxpayer ID' field displays as 'X’.

Adyen Smart Payments Now Supports Mandate Signature Date For SEPA (DEV-11318)

Aria now accepts an externally created Mandate ID and Mandate Signature Date for SEPA Direct Debit payments as part of the Adyen Smart Payments integration. This applies to the Direct Debit (26) and Tokenized Direct Debit (37) payment methods. The Mandate Signature Date is sent (input parameter) and returned (output parameter) via the following Aria APIs:

The mandate date must be in the format of YYYY-MM-DD. The <mandate_id> and <mandate_signature_date> will be acknowledged solely upon validation and/or acceptance by Adyen. In case of any issue with the inputs passed, Adyen will generate their own <mandate_id>, <mandate_auth_date>, and <sequence_type> (<sequence_type> is an internal value based on the payment; values are 1 for First and 2 for Recurring).

get_refund_details_m Returns Tax Lines for Reversed Items (DEV-11373)

This feature addresses an issue in which the get_refund_details_m API call did not return the tax line item of a reversed charge line when you reversed the full amount of an invoice. Now, Aria returns the tax line items of reversed charges for invoices that were refunded and reversed for the full amount.