Release 27

Enhanced Behavior For Removing Child Plans From Plan Relationships (DEV-9467)

While editing a plan in the Aria UI, and you attempt to remove a Child Plan on the Plan Relationships tab: If the Child Plan relationship is mapped to at least one account, you will receive a popup message explaining "This plan is currently in use...", and will not be able to remove the Child Plan on the Plan Relationships page.

If the Child Plan is not mapped to at least one account, and the Child Plan is not mapped to any other Parent Plan, you will receive a warning message stating that the Child Plan will be "orphaned," but you will be allowed to remove the plan.

See Define Plan Relationships for more information.

CIT and MIT Support Available for Vantiv Transactions (DEV-9716)

• Aria's integration with the Vantiv payment gateway has been enhanced with support for Cardholder Initiated Transactions (CIT) and Merchant Initiated Transactions (CIT) for the Mastercard and Discover credit cards. This feature allows you to specify whether you are processing a cardholder- or merchant-initiated transaction and whether the card information is already stored in Aria.​
• To do so, use the pre-existing <recurring_processing_model_ind> ​input and <proc_initial_auth_txn_id> output in these APIs:

• validate_acct_fraud_scoring_m
• manage_pending_invoice_m
• update_acct_billing_group_m
• collect_from_account_m
• update_payment_method_m

• The new Send orderSource as recurring for all transactions setting is now available in your payment gateway and/or collection group configuration for Vantiv. This new setting allows you to send the orderSource field* value to Vantiv as recurring, regardless of the value that you passed into the <recurring_processing_model_ind> field.

* The orderSource field indicates the type of payment. Please contact your Vantiv representative for more information.

Vertex O Series Version 9 Support (DEV-9763)

The Aria Vertex tax integration has been enhanced with support for Vertex O-Series version 9 for both the on-premises and the cloud hosted functionality. To use this new version of Vertex O-Series, enter 9 in the DocVersion field in your Vertex O-Series configuration.

Please contact your Vertex representative for more details.

New First Data Payeezy Endpoint for Tokenization (DEV-9775)

First Data Payeezy has changed its endpoint for credit card tokenization. This means that if you use Payeezy to process tokenized credit card payments, no later than March 15, 2020, you will need to update your Payeezy configuration settings. To do so, enter the required value in the new Transarmor Token field in your Payeezy configuration settings to connect to this new endpoint. This is required for only US merchants.

Please contact your Payeezy representative ​for more information.

Plan Billing Intervals in Days or Weeks (DEV-9787)

You can now create plans whose billing intervals are your specified number of days or weeks, a feature called Daily-Weekly Billing. Please note that this enhancement will be released in phases. This phase will include support for

• standard invoicing,
• bill lag days on account-level Master Plan Instance, and
• proration for plan cancellation and plan unit modification. 

Notes Regarding Daily-Weekly Billing

• Daily-Weekly Billing does not support Usage Accumulation. When an account updates from a rate schedule with a monthly billing interval to rate schedule with a daily or weekly rate schedule for a plan with Usage Accumulation, Aria resets the Usage Accumulation. When an account updates from a rate schedule with a daily or weekly billing interval to a rate schedule with a monthly billing interval, Usage Accumulation becomes available again as a plan option.
• You cannot update an existing rate schedule on a plan from a monthly to a daily or weekly billing interval. You must create a new rate schedule on existing plans to use Daily-Weekly Billing.
• The allowable value for Bill Lag Days is dynamically calculated as 1 day less than billing interval.
  • For example: For a 5-day billing interval, the allowable value for bill lag days is +/- 4 days. For a 3-week billing interval, the allowable value for bill lag days is +/- 20 days.
  • An error message results if you enter a number greater than the billing interval.
  • If the ‘Allow bill lag days to extend beyond 1 billing cycle’ client parameter is set to TRUE, you can set Daily-Weekly Bill Lag Days on a Master Plan Instance to a value greater than its billing interval.

Learn more about specifying billing intervals when creating rate schedules.

OAuth 2.0 Token Based Event Notification (DEV-9792)

Aria now offers oAuth 2.0 communication as a choice for Authentication Type when configuring event notifications in the Aria UI. Other Authentication Types include None and Basic HTTPS.

Learn more about Event Methods.

Application Fixes 

• The Administrative Audit Log under Configuration > Audit Logs > Administrative no longer shows "Create Functionalaccountgroups Success" if a functional account group has not been created. (TICKET-16305)
• These fixes have been implemented on the Create New Account Template screen: (TICKET-16945)
  • Under Invoicing Options, your Default Value selection of Use client default is saved and not displayed as Perform prorated invoicing.
  • Under Collection Account Group, if you set Display to No, the Collection Account Group field is no longer displayed.
  • Under Contact Details, if you set Display to No, for the MI (middle initial) field, that field is no longer displayed.
  • Under Notification Template Group (NTG), any NTGs that you created are displayed in the Default Value dropdown, as expected.
• You can now create a surcharge in the Aria UI, and assign a default rate schedule for the expected currency, successfully. Previously, the "Make Default" checkbox in the Rate Schedule configuration form showed "usd" regardless of the currencies configured in the Aria instance. (TICKET-17089)
• You can now successfully remove a Service Name translation, from Products > Services > (Select a Service) > Click Translations link next to Service Name, for Service Names with multiple translations. (TICKET-17481)
• After copying an Aria configuration  to another client, the Account Fields screen under Configuration > Client Settings in the destination client now loads correctly (even if any account field names had characters that were URL encoded or included spaces). (TICKET-17652)
• Aria now sends to external tax engines all transaction data needed to properly calculate taxation, including tax exemption, on partial refunds. (TICKET-17677)

New Billing Contact Input Fields Added (DEV-9637)

The new input fields <bill_drivers_license_no>, <bill_drivers_license_state>, and <bill_taxpayer_id> are now available in these APIs:

•  authorize_electronic_payment_m
•  collect_from_account_m
•  create_order_m
•  create_order_with_plan_m
•  manage_pending_invoice_m
•  settle_account_balance_m
   

Note: The input fields listed above were non-public in previous versions of Aria and they are now public.

Anniversary Date Support Added for Custom Rates (DEV-9651)

Aria now supports using the update_acct_plan_multi_m and update_acct_plan_m​ APIs to schedule <custom_rates> that have a future <assignment_directive> and an <effective_date> of the anniversary date​.

Braintree Support for 3D Secure Authentication 2.0 (DEV-9730)

Aria's integration with the Braintree payment gateway has been enhanced with support for 3D Secure (3DS) authentication 2.0. The 3DS authentication feature provides additional fraud prevention when transactions are processed.

To perform 3DS authentication 2.0, use the following new fields in these APIs as described in the authorize_3dsecure_m documentation:

Please contact your Braintree representative ​for additional information about using 3DS 2.0.

Customize Dunning Options (DEV-9743)

You can now use the APIs listed below to do one or more of the following:

• change a plan's dunning step or dunning degrade date; or
• specify whether to use dunning plan configuration to charge a late fee or send the customer a dunning email notification or suppress those actions.

To apply the dunning options mentioned above, use these new fields available in the following APIs:

Additional Fields To Be Anonymized (DEV-9747)

When you call the delete_acct_data_m API, the following additional account contact fields considered Personally Identifiable Information (PII) are now anonymized, as expected:

• <city>
• <locality>
• <zip>
• <cell_phone>
• <phone_suffix>
• <intl_cell_phone>
• <intl_work_phone>
• <fax_phone>
• <work_phone>
• <phone_country_code>

CyberSource Support for 3D Secure Authentication 2.0 (DEV-9765)

Aria's integration with the CyberSource payment gateway has been enhanced with support for 3D Secure (3DS) authentication 2.0. The 3DS authentication feature provides additional fraud prevention when transactions are processed.

To use 3DS 2.0:

1. Configure the Payer Authentication Settings in the Aria application's payment gateway and/or collection group screens for CyberSource; and
2. Use the following new fields in these APIs as described in the authorize_3dsecure_m documentation:
    

   APIs	New Inputs	New Outputs
   authorize_3dsecure_m authorize_electronic_payment_m update_payment_method_m	In the <proc_field_override> array: <payer_auth_reference_id> <payer_auth_transaction_id> <payer_auth_transaction_mode>	Allowable values in the <proc_3dsecure_data> in authorize_electronic_payment_m /<proc_3dsecure_auth_data> array in update_payment_method_m: <pa_3ds_form_action> <pa_3ds_js_lib_url> <payer_auth_reference_id> <payer_auth_transaction_id> The <proc_3dsecure_data> output array has been added to the authorize_3dsecure_m API.

Please contact your CyberSource representative ​for additional information about using 3DS 2.0.

Adyen Support for 3D Secure Authentication 2.0 (DEV-9766)

Aria's integration with the Adyen payment gateway has been enhanced with support for 3D Secure (3DS) authentication 2.0. The 3DS authentication feature provides additional fraud prevention when transactions are processed.

To use 3DS 2.0:

1. Configure the Payer Authentication Settings and API URL in the Aria application's payment gateway and/or collection group screens for Adyen; and
2. Use the following new fields in these APIs as described in the authorize_3dsecure_m documentation:

Please contact your Adyen representative ​for additional information about using 3DS 2.0.

Plan Instance Information Now Sufficient Identifier for Usage APIs (DEV-9778)

Passing only Plan Instance information, without account-specific fields, is now sufficient to make successful calls to the record_usage_m and bulk_record_usage_m APIs. 

Previously, the fields <acct_no>, or <userid>, or <client_acct_id> were required, in addition to the fields <plan_instance_no> or <client_plan_instance_id>, to successfully record usage records for an account in Aria.

Plan Billing Intervals in Days or Weeks (DEV-9787)

You can now create plans whose billing intervals are your specified number of days or weeks, a feature called Daily-Weekly Billing.

The following Admin Tools APIs have been updated with two new fields, <recurring_billing_period_type> and <usage_billing_period_type>, to accommodate Phase 1 of this new feature. Subsequent phases supporting additional features will be included in forthcoming releases.

In addition, because Daily-Weekly Billing does not support Usage Accumulation, the following APIs return the error, “Usage accumulation is not supported by daily/weekly billing interval," if you try to configure a Daily-Weekly plan with Usage Accumulation:

• create_acct_complete_m
• update_acct_complete_m
• update_acct_plan_multi_m
• replace_acct_plan_m
• assign_acct_plan_m
• update_acct_plan_m

API Fixes  

• XML Exception error: Unexpected element: CDATA was being displayed in authorize_electronic_payment_m API response instead of in the correct XML format (TICKET-16091)
• When you call the create_payment_terms_m API and pass in a <functional_acct_group_no>, your specified account group is now reflected for that payment term in the Aria application. (TICKET-17285)
• The proration service credit amount is now calculated correctly when you use the update_acct_plan_multi_m API to cancel a master plan and add a supplemental plan associated with a different master plan. (TICKET-17630)
• The get_invoice_history_m API now returns invoice data for your specified master plan instance (MPI), even if the MPI's current billing group differs from the billing group originally associated with the MPI when the invoice was generated. (TICKET-17664)
• When you use an API to assign a master plan (MP) along with a supplemental plan (SP) that has an annual billing interval, as expected, the SP is billed annually, instead of monthly. (TICKET-17676)
• The "servercouldnotcollectfromacct" error message is no longer returned and the payment is now collected when you use a Direct Post configuration to attempt a payment collection. (TICKET-17724)
• When you use the update_acct_plan_multi_m to modify a billing group and you pass in a <primary_client_payment_method_id>, the "unexpected" error message is no longer returned and the billing group is updated, as expected. (TICKET-17730)