Release 48

Client Parameter "Net Negative Proration Action" (Related to DEV-3740)

After Release 48, if this parameter value is set to "Produce Cash Credit for Net Negative Amount", and you initiate a plan change via update_acct_plan_multi_m resulting in a prorated credit, then a cash credit will be issued for the net negative amount as expected. We fixed a bug in which:

• the parameter Configuration > Billing > Invoice Settings > Net Negative Proration Action is set to ‘Produce Cash Credit for Net Negative Amount’, but
• when you initiate a plan change via the API call update_acct_plan_multi_m, a prorated service credit results instead of a cash credit. 

Discount Bundles With Non-Overlapping Discount Rules (Related to DEV-10551)

To repair a reported backward compatibility issue, we reverted discount bundle behavior when the discount rules in the bundle are set to not overlap. Consider the following example of a discount bundle:

Prior Behavior: Discount bundle is valid when all discount rules are valid.
Only the 1st discount rule on the bundle will be applied to invoices. After the 1st discount rule has expired, the bundle will expire without the 2nd discount rule getting applied for the next two months. 

Post-Release-48 Behavior: Discount bundle is valid when one of the discount rules is valid.
Both discount rules will be honored and applied accordingly. The 1st discount rule will be applied to the first six months, then the 2nd discount rule will be applied to the following two months.

You can set overlap behavior either 1) via the API call create_discount_bundle_m, setting the input field <allow_overlap_ind> to ‘No’; or 2) in the Aria UI, Marketing > Discount Bundles, and clicking the ‘No’ radio button for ‘Allow Overlap’. 

Automated Refund of Net Negative Charges from Prorated Actions (DEV-3740)

As an alternative to creating service or cash credits, it is now possible to configure Aria to automatically refund net negative charges resulting from the proration of plan cancellations and downgrades. 

To initiate an automated refund for a prorated action that results in net negative charges, two client parameters must be set up to work in tandem. A new client parameter Refund for Proration Credit Action (Configuration > Payments > Payment Settings) must be activated and set to either the, "Refund for Cancellation" or "Refund for Cancellation or Downgrade" option, which provides flexibility for handling refundable plan changes. Then set the Net-Negative Pro-Ration Action client parameter (Configuration > Billing > Invoice Settings) to either the "Produce Cash Credit for Net Negative Amount” or the “Produce Corresponding Cash Credit” option. The Net-Negative Pro-Ration Action client parameter allows you to configure whether to issue service credit, cash credit, refund or discard in these cases. 

Once set up, an automated refund can occur upon UI actions in the Plans screen for Remove Plan, Replace Plan, or Change Plan Units that could cause a net negative charge upon proration. In the UI, you will see automated refund transactions in the Refunds (Accounts > [select account] > Payments & Credits) and Transactions (Accounts > [select account] > Statements & Invoices) screens. A new uneditable (read-only) "Plan cancellation or downgrade automated refund" reason code was introduced that describes the cause of the transaction is listed in Finance > Reason codes and populates transaction data table descriptions. 

IMPORTANT: To use this feature, be aware that only one-time, fully paid invoices are eligible for automated refund. If multiple payments or payment methods were made to pay an invoice, it will not be processed. In these cases, the action will result in the error message, "Automated refund is not issued for invoice [invoice no] due to payment is ineligible for automated refund or the original payment method is invalid". If a refund attempt fails, a prorated cash credit is issued to the account holder. 

Refunds Now Provided Using Disabled Cards for Payment Collection (DEV-10350)

Frequently, you encounter a scenario where payment is made from a card that has been disabled, but a refund is requested later against that disabled card. Aria now accommodates that use case, as long as that card is not expired (previously, such refunds were disbursed by check only).

When issuing a refund from above (Account > [search for an account] > Plans > Payments & Credits > Refunds), payment can be disbursed against a previously authorized card that is currently disabled. Two refund options appear, as follows:

Original
Original or Check Number (A refund will be attempted using the original pay method, but if that fails, a check will be issued.)
Learn more about issuing a refund from here.

Relaxed Validation for Child- to Parent-Pay Conversions for Subscriptions in Dunning (DEV-10513)

This feature relaxes validation for child- to parent-pay Conversions for subscriptions in Dunning. Now, child subscriptions in Dunning mapped to billing groups with payment methods can be converted to parent-pay, while those mapped to billing groups with payment terms are still prevented from this conversion. For the API calls update_acct_plan_m, update_acct_plan_multi_m, update_acct_complete_m, and set_payment_responsibility_m–if the payment terms dunning condition exists–an error is returned. In the Manage Child Accounts screen of the Aria Billing applicaion, a warning is shown for such conditions, and you are prevented from converting payment responsibility to a parent MPI that is also mapped to payment terms.

New "Attach Qualifier Option" Global Parameter (DEV-10549)

Aria has introduced a global parameter called Attach Qualifier Option (attach_qualifier_option). This parameter gives you the ability to pass transaction qualifiers for all transactions for a selected API (i.e., the existing behavior) or only for newly created transactions for a selected API (enhanced behavior). This global parameter can be applied to issue_refund_to_acct_m, record_out_going_payment_m, and all other transaction APIs. For example, by enabling this parameter for a new transaction only (via record_out_going_payment_m), the transaction qualifier can be stored for a refund and not the original payment transaction. 

Options for the new global parameter Attach Qualifier Option are A (All) and N (New) where: 

A, Transaction qualifiers will be attached to all transactions, that is, relevant transactions and newly created transactions. The ALL value is the default for backward compatibility. Null values will default to ALL behavior. 
N, Transaction qualifiers will only be attached to a newly created transaction.
In addition, validation has been added to alert you to invalid input and will result in the error message, "1016: Allowable values for attach qualifier option are A (ALL) or N (NEW)". 

Discount Bundle Usage Expanded for Member Discount Rules (DEV-10551)  

Previously, a discount bundle could not be used when any of its member discount rules had expired. In the current release, this limitation has now been removed, allowing the discount bundle to be used if at least one of its member rules remains in effect. 

Note: This enhancement was intended to allow sequentially tiered discounts to be applied on invoices based on discount rules order in a discount bundle, specifically when discount rules are set to not overlap. To apply this behavior, select the No overlap option during discount bundle creation. Go to Marketing > Discount Bundles > Create New Discount Bundle.  

For more information, refer to the Discount Rules and Discount Bundles articles.

Validation Added to Reversal Amount for Refunds (DEV-10808)

To enhance the processing of refunds with reversals, inline text validation of the refund amount has been added to the Refunds screen in the Total Amount to Refund editable field. This ensures that when you enter an amount in this field, that the maximum refundable amount is not exceeded and also informs you when the amount is less than the refund limit.

For example, if the amount is over or less than the maximum refundable amount (i.e., invalid entry), "Amount entered is not within allowable range" will appear in red text below the Total Amount to Refund field. To the right of the field, a "Maximum refundable amount is [value]" line will appear to inform users of the refund limit. In addition to the validation, the advisory note with the yellow background on the screen has been supplemented with a line that informs you that for refunds with reversals, it is possible to enter an amount greater than the total of the line reversal but less than or equal to the maximum refundable amount.

Tokenized ACH Added As Payment Option During Account Creation (DEV-10832)

With this release, Aria introduces Tokenized ACH as a payment method that can be selected during account creation (Account > Create an Account > Plans > Payment Options). ACH (for Automated Clearing House) payment tokenization replaces an account and routing number with a random string of alphanumeric data for added account security.

Tokenized ACH is supported by selected payment providers. Please refer to supported payment gateway features for further details.

Functionality Enhancements for Adyen Along With Aria Payment Processor Integrations (DEV-10860)

The following enhancements have been introduced by Aria to streamline payment efficiency for Aria-supported payment processors.

For All Payment Gateways/Collection Groups:

• The Processor Details and Gateway Options tabs have been renamed to Merchant Account Details and Processing Options, respectively, at the payment gateway and collection group levels.
• Additionally, at the Processing Options tab, the Fraud Options and Payer Authentication Settings section headings have been renamed FraudScoring Options and 3DS Authentication Settings for each processor.

For Adyen:

• Merchant Account Credentials and Webhook Notifications have been added as section headings for Merchant Account Details at the payment gateway and collection group levels.
• The Merchant Account Name field in the Merchant Account Credentials section has been expanded from 20 to 40 characters.
• Click here for more information on the Adyen payment processsor.

Dunning Enhancements Offer More Robust Dunning Plan Specification (DEV-10891) 

Aria has enhanced Dunning plans by increasing the maximum number of steps from eight to 20; enabling you to configure whether or not the system should attempt a collection; and providing a field to specify a Dunning step description that will be included in the event provisioning payload for Dunning events.

API Support for Automated Refunds for Net Negative Charges from Proration (DEV-3740)

The functionality of the following APIs have been enhanced to support the new automated refunds feature for net negative charges from proration resulting from prorated plan actions (cancelling, replacing, or changing units). 

• cancel_acct_plan_m
• update_acct_plan_m
• replace_acct_plan_m
• update_acct_plan_multi_m
• edit_acct_plan_queued_changes_m

No new parameters were introduced for the APIs as a result of the changes. To initiate, required client parameters Refund for Proration Credit Action and Net-Negative Pro-Ration Action must be set appropriately, as described in the "Automated Refund of Net Negative Charges from Prorated Actions (DEV-3740)" release note in the Application Features section. 

Improved Error Messages for update_acct_plan_multi_m and edit_acct_plan_queued_changes_m (DEV-10029)

This feature improves invoiceing error messages returned for update_acct_plan_multi_m and edit_acct_plan_queued_changes_m for invoice generation, subscription changes, and subscription cancellations on test accounts. The affected error messages can also be viewed when generating an invoice with the create_order_m and create_order_with_plan_m APIs.

Enhancements to get_daily_batch_status_m (DEV-10148)

The get_daily_batch_status_m API has been enhanced to return relevant batch process status outputs for all client batch processes, specifically, the <batch_process_id>, <batch_process_name>, <batch_process_status> outputs with a specified <batch_date> input parameter. New <include_all_batches> and <batch_process_id> inputs provide list and fetch reporting capabilities for all and specific batches, respectively. By default, <include_all_batches> is set to "false". The change also introduces two new output parameters with <batch_process_name> and <batch_process_status> in the <batch_process_details> array. The <status> output parameter has been deprecated and replaced by <batch_process_status>.

The following input parameters were added to the get_daily_batch_status_m API:

The following output parameters were added to the get_daily_batch_status_m API:

Refunds Now Provided Using Disabled Cards For Payment Collection (DEV-10350)

With this feature, refunds/authorization reversals can now be processed using a disabled credit card when issuing a refund via the issue_refund_to_acct_m API. There are no changes to input or output fields; only existing validation preventing a refund on a disabled card has been removed.

Relaxed Validation for Child- to Parent-Pay Conversions for Subscriptions in Dunning (DEV-10513)

This feature relaxes validation for child- to parent-pay Conversions for subscriptions in Dunning. Now, child subscriptions in Dunning mapped to billing groups with payment methods can be converted to parent-pay, while those mapped to billing groups with payment terms are still prevented from this conversion. For the API calls update_acct_plan_m, update_acct_plan_multi_m, update_acct_complete_m, and set_payment_responsibility_m – if the payment terms dunning condition exists – an error is returned. In the Manage Child Accounts screen of the Aria Billing application, a warning is shown for such conditions, and you are prevented from converting payment responsibility to a parent master plan instance (MPI) that is also mapped to payment terms.

ACH/Electronic Check Account Validation Added for Aria APIs (DEV-10756)

To enhance payments via ACH/electronic check (payment method 2), Aria has introduced the <bank_acct_type> input to the following selected APIs:

• assign_acct_plan_m
• create_acct_billing_group_m
• create_acct_complete_m
• update_acct_billing_group_m
• update_acct_complete_m
• update_acct_plan_multi_m
• update_payment_method_m
• Values for this new input field are Savings, Checking, or Business.

The following existing error message will now be returned for these APIs if the <bank_acct_type> field is not populated for payment method 2:

Dunning Enhancements Offer More Robust Dunning Plan Specification (DEV-10891) 

Aria has enhanced Dunning plans by increasing the maximum number of steps from 8 to 20; enabling you to configure whether or not the system should attempt a collection; and providing a field to specify a Dunning step description that will be included in the event provisioning payload for Dunning events.