Release 43

Apple Pay Payment Method Now Included In Chase Paymentech Integration (DEV-10093)

Aria is excited to introduce Apple Pay as a digital payment method to our Chase Paymentech integration. Tokenized payments are supported for the Visa®, Mastercard®, American Express® and Discover® card types.

To configure Apple Pay for Chase Paymentech, navigate to the Apple Pay tab (Configuration > Payments > Payment Gateways/Collection Groups [Chase Paymentech]). 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. More information is provided in DEV-10605.

---

New Usage Rating Timing Options (DEV-10122)

It is now possible to control usage rating timing at the usage type level. Previously, this was only possible via a client parameter. When in the UI creating a new “Usage Type” via Products > Usage Types > [select New button], use the new Rating Timing drop-down to set usage rating timing to follow client parameters "at invoicing" or "at loading". The new drop-down is available on the Create New Usage Type screen located beneath the Usage Unit Type drop-down.

The Rating Timing drop-down options are as follows:

Option Name	Description
Usage Rating Parameter	(Default) Selects the current, global client parameter (True or False) setting for "Automatically Rate Un-rated Usage Records at Load Time" located in Configuration > Billing > Invoice Settings. The client parameter remains in place as default unless explicitly set to another option.
Rated at Invoicing	When selected, usage will be rated at the time of invoice processing. This option overrides the default client parameter for that usage type only.
Rated at Loading	When selected, usage will be rated during usage loading to the platform. This option overrides the default client parameter for that usage type only.

---

New Fields Added for Coupon Definition and Assignment (DEV-10137)

In the Aria UI, the following new fields have been added when assigning a coupon to an account or master plan instance in the Coupon Details screen at the bottom of the screen in the order shown below: 

Field Name	Description
Reason Code	To utilize the reason code field, you need to set the reason code for a coupon via Finance > Reason Code. A new coupon reason code type was introduced to support this functionality.
CSR Comments	Use this field to record any important notes about the coupon.
Effective Date	Effective date defaults to the current date (or client virtual date). You can set effective date to be in the future. Effective date does not support a past date, but it will work with plan retroactive date. For example, suppose you assign a coupon with an effective date of today's date. After initial coupon assignment, it is assigned to a plan with a retroactive start date (e.g., a week before today's date). The coupon will be applied to the plan and will follow the retroactive date of the plan.

Getting here: Go to Accounts > Payments & Credits > [select an Account] > Coupons tab. If there already is a coupon assigned to this plan or account, at the bottom of this screen there is an All Plans coupons listing. Click on the name of an assigned coupon hyperlink to open its Coupon Details screen. Alternatively, click Assign Coupon and at the end of this workflow you will encounter the Coupon Details screen. In addition to the added fields described above, new Assignment Number and Assignment Date (formerly Create Date) columns containing field values will be displayed in the All Plans Coupon listing. 

---

New Remainder Discount Rule for Prorating Fixed Amount Discounts (DEV-10593)

To extend the functionality of Remainder Discount Rules from the prior release, Aria is now introducing a new rule for proration on remainders on fixed amount discounts; that is, when the first invoice on a plan is prorated, then its fixed amount discount will be prorated. A fixed amount discount here refers to the total monetary discount applied to the charge as opposed to a percentage discount. In the UI, you will encounter this feature in the Invoice Application drop-down in the Create a New Discount Rule screen. 

Getting here: Go to Marketing > Discount Rules > [New button]. In the Invoice Application drop-down, choose the "Use proration and remainder factors" option. The default setting does not apply proration to remainders. 

For more information on creating new discount rules, click here. 

---

Dunning Step Now Displayed in Account Balance Details (DEV-10598)

This feature updates the Balance Details section on the Account Overview screen. In the Dunning State column, the step of Dunning for the affected plans now shows after the Dunning state label. 

---

Aria APIs Enhanced for Chase Paymentech/Apple Pay Payments (DEV-10605)

After generating and uploading the .cer format file to enable Apple Pay payments through Chase Paymentech (described in DEV-10093), you can contact Aria with the Apple Pay payload generated outside of Aria. To accomplish this, an input field has been added to the existing record_alternate_payment_m API.

Input Field Name	Description
<external_payment_payload>	This accepts the Apple Pay encrypted payment payload. Using your payment processing certificate, Aria will decrypt the payload and store the token for future payments.

While executing the record_alternate_payment_m API (with as 47 for Tokenized Apple Pay), Aria will decrypt the payload and the decrypted values will be used for completing the initial payment to Chase. This API sends the payment to Chase Paymentech; then, Chase will post the payment the next day to complete the Apple Pay payment.

After the token is created, Aria will use the token for supporting the recurring Apple Pay payment as part of your Chase Paymentech integration. Electronic refunds are supported for both the initial and recurring Apple Pay transactions.

In addition to the newly added field above, Aria has also introduced the following input field to the record_alternative_payment_m API:

Input Field Name	Description
<primary_payment_method_ind>	Indicates the Apple Pay billing record to be created as primary payment method for the billing group mapped in the passed statement number. The default is 0. If we pass as '1', then the billing record will be created as primary pay method for the billing group associated with the statement number.

As a reminder, Apple Pay tokenized payments are supported for the Visa®, Mastercard®, American Express® and Discover® card types.

Learn more about Aria’s Chase Paymentech integration from here.

---

XML Statement Number Added To Selected UI Screens (DEV-10611)

To enhance processing of XML Statements, the XML Statement No. column has been added to the following screens:

• Account Overview > Recent Statements
• Account > Statements & Invoices > Statements Tab
• Account > Plans > Recent Statements

Notes:

The XML Statement Distillation setting must be configured to receive XML statements (Configuration > Notifications > Notification Settings).

• In case there is more than one XML statement for a given statement number, the latest XML statement will be returned.

In addition, the 1042 Event Payload (Account Message Type "XML Statement" Requires Sending) has been updated with the statement_no and invoice_no fields.

Learn more about Events in the Accounts and Master Plan Instances Notification Class from here.

---

Romanian New Leu Currency Code Update (DEV-10632)

To comply with currency redenomination requirements, Aria has renamed the existing RON currency code from New Romanian Leu to Romanian New Leu (Configuration > Billing > Currencies).

---

New Aria Parameter Allows Cancellation for Plans In Dunning (DEV-10641)

A parameter has been added to perform future and immediate Master Plan Instance (MPI) cancellations even if the plan is in dunning (Allow Master Plan Instance Cancellation While Master Plan Instance is in Dunning). If “Allow” is selected, the MPI can be cancelled (immediately or in the future, including on anniversary) when the MPI is in Dunning. If “Do Not Allow” is selected, the MPI cannot be cancelled (immediately or in the future, including on anniversary) when the MPI is in Dunning. The default is “Do Not Allow” (Configuration > Payments > Payment Settings), which is existing behavior.

Note: A plan will remain in Dunning after cancellation since a balance is outstanding against the plan.

---

Application Fixes 

• Oauth 2.0 for event notifications now correctly refreshes the token automatically when the token expires. Aria provisioning daemon will refresh the token and upon successful payload submission with the new token, it will refresh the right status code and track the status as success and maintain the appropriate status code for further payload submissions (TICKET-18769)
• Fixed an issue to properly log the status of the batch job when it is completed with some errors. Previously, the log entry would be blank and the stamp time empty. Both entries are now populated appropriately.  (TICKET-18770)

---

Enhancement to Invoice Processing For Future Plan/Replace Actions (DEV-9705)

Aria introduces enhancements to invoice processing for future plan update/replace actions as part of this release. With the anniversary date as the effective date, the following queued inputs are now honored:

• Coupons (Attach/Detach)
• Surcharges (Add/Remove)
• Plan instance fields (Assign/Remove/Replace)
• Custom rates (Assign/Remove)
• Plan instance attributes (such as New Client Plan Instance ID, Plan Instance Description, Promo Code, and PO Number) (Update)

This applies to the following input fields/APIs:

Category	Fields	Affected APIs
Coupons	<coupon_cd>	update_acct_plan_multi_m (<coupon_codes_updates> array)
	<coupon_directive>	Same as above Note: This is now honored for a ‘replace’ plan action when it is queued for future assignment with the effective date as the anniversary date via update_acct_plan_multi_m. This field is already honored for the ‘update’ plan action.
Surcharges	<mp_surcharge_no>	update_acct_plan_m (<mp_surcharges> array)
	<mp_surcharge_rate_schedule_no>	Same as above
	<mp_surcharge_directive>	Same as above
Plan Instance Fields	<plan_instance_field_name>	update_acct_plan_m (<plan_instance_field_update> array)
	<plan_instance_field_value>	Same as above
	<plan_instance_field_directive>	Same as above
Custom Rates	<custom_rate_service_no>	update_acct_plan_m (<custom_rates> array)
	<custom_rate_seq_no>	Same as above
	<custom_rate_to_unit>	Same as above
	<custom_rate_per_unit>	Same as above
	<new_client_plan_inst_id>	update_acct_plan_m
	<plan_instance_description>	Same as above
	<promo_cd>	Same as above
	<po_num>	Same as above

When there is more than one future plan update/replace action queued on the same effective date, only the latest queue will be executed and others will be ignored. For example, when there are two future plan update actions queued on same effective date, the latest update action will be honored, and if both replace and update queues are present (irrespective of their order), then only the replace action will be honored. This existing behavior now aligns with the future-plan queue batch job behavior.

If any queued inputs like coupons or surcharges fail to get processed successfully, then the other queued inputs like new plan number and alt rate schedule will not be applied/processed. Such queues will be marked as ‘failed/error’.

This applies to the following API inputs:

Input	API
<new_plan_no>	replace_acct_plan_m
<plan_units>	Same as above
<alt_rate_schedule_no>	Same as above
<remove_pi_custom_rates>	update_acct_plan_m Note: The <remove_pi_custom_rates> value is now honored for master plan instances (MPIs) as well as for future queues with the effective date as the anniversary date. This is existing behavior for supplemental plan instances (SPIs). Where there are both future ‘replace and update plan’ actions queued with the effective date as the anniversary date, only the replace action will be honored.

The following example illustrates what occurs if you want to attach a coupon to a plan instance along with a plan replacement and plan units change via replace_acct_plan_m API (for a future effective date with ‘anniversary date’ as effective date). While dequeuing the inputs, if the queued coupon does not get processed successfully (maybe the coupon is already attached to the plan instance), then the other queued inputs such as <new_plan_no> and <plan_units> will not get updated to the plan instance. The replace plan queue will be marked as failed in this case.

---

API Support for New Usage Rating Timing Options (DEV-10122)

For API support of the newly introduced Rating Timing feature at the usage type level, a new flag called <usage_rating_timing> was taken from the global/client parameter level and was implemented in API calls that support this functionality.  

The <usage_rating_timing> flag has been employed in the following APIs in the manner indicated in the table below:

Affected API	USAGE_RATING_TIMING Values (if applicable)	Argument Type
record_usage_m	(N/A) No setting was implemented. This only required a new usage_rating_timing flag to ensure if any usage type passed on this API will correctly refer to values defined by client parameter setting.	N/A
bulk_record_usage_m	Same as above	N/A
create_usage_type_m	Null - Refers to default client parameter "Automatically Rate Un-rated Usage Records at Load Time" invoice setting value (True or False) 0 - At Invoicing 1 - At Loading	Input
get_usage_types_m	Same as above	Output
get_usage_type_details_m	Same as above	Output

---

New Coupon Assignment Attributes and Controls (DEV-10137)(1 of 2)

For assigning a coupon to an account or master plan instance in Aria, new attributes and controls have been added to the respective account coupon application APIs, apply_coupon_to_acct_m and get_acct_coupon_details_m.  

The new attributes and controls in the above APIs are as follows:

Attribute Name	Type	Length	Description
<coupon_assignment_reason_cd>	long	22	The code of the reason the coupon is being applied.
<coupon_assignment_comments>	string		Any important comments about the coupon to be noted.
<coupon_assignment_effective_date>	string	10	The date the coupon will take effect on the account/plan instance, in yyyy-mm-dd format.
<override_discount_rule_scope>	hash		This field overrides the discount rule scope set within Marketing Catalog.

The <override_discount_rule_scope> attribute contains a number of nested array input options that can take different values:  

• rule_no (type=long, length=22) - Discount rule number associated to the coupon.
• client_rule_id (type=string, length=100) Override scope number.
• scope_no (type=long, length=22) Array of plans which can be overridden. 
  • Values: 0 - All charges; 10 - All Plan Charges, All Plans; 11 - All Plan Charges, Specified Plans; 12 - All Plans, Specified Service Charges; 13 - Specified Plan/Service Charges; 21 - All Recurring Service Charges; 22 - All Usage Service Charges; 23 - All Activation Service Charges; 30 - All Item Charges; 31 - Specified Item Charges
• plan_service_detail - Array of plans which can be overridden.
  • Nested arrays: type, client_plan_id, service_detail, item_detail

The <override_discount_rule_scope> attribute returns the following: 

• user_success_mg (type=string) - The message to display to account the holder upon successful application of the coupon code they have provided.
• coupon_assignment_no (type=long, length=22) The ID assigned to the coupon.
• coupon_assignment_effective_date (type=string, length=10) - The date the coupon will take effect on the account/plan instance, in yyyy-mm-dd format.

For more information on these API controls and attributes, see relevant information in the apply_coupon_to_acct_m and get_acct_coupon_details_m API topics as it becomes available. 

---

Validation Added for Override Discount Rule Scope Attributes (DEV-10137)(2 of 2)

Validation has been added for the new <override_discount_rule_scope> attribute and its values for apply_coupon_to_acct_m and get_acct_coupon_details_m APIs, introduced in the previous DEV-10137 release note item. 

Be aware of the following validation and relative behavior when using <override_discount_rule_scope> attributes:

• For rule_no and client_rule_id, if a rule number is specified that is not a part of the coupon, the following error message is issued:

Error Code	Error Message
15019	Discount rule no or id is invalid or blank

• For scope_no, allowable values follow the create_discount_rule precedent. 
  • If users enter any of these allowable values, then they MUST to specify plans/service/items:
    • 11 - All Plan Charges, Specified Plans
    • 12 - All Plans, Specified Service Charges
    • 13 - Specified Plan/Service Charges
    • 31 - Specified Item Charges
  • If users enter values 0,10, 21, 22, 23, or 30, there is no need to specify plans/service/items. Any supplied plans/service/items in the API will be ignored.
  • If an invalid scope_no is entered, the following error message is issued: 

Error Code	Error Message
15021	Plans on override discount rule scope can not be blank

• To override discount rule scope set in the Marketing Catalog, add the following parameters in a similar manner to how users define applicable plans/services/items with the create_discount_rule_m API:
  • Plans array (plan_no OR client_plan_id)
  • Service array (service_no OR client_service_no)
  • Item array (item_no OR client_sku)
  • Validations listed below:

Error Condition	Error Code(s)/Message(s)
User enters scope_no "11" but plan not provided	15021 - Plans on override discount rule scope can not be blank
User enters scope_no "11" but plan is invalid	15022 - Plans on override discount rule scope are invalid
User enters scope_no "12" but service not provided	15023 - Services on override discount rule scope can not be blank
User enters scope_no "12" but service is invalid	15024 - Services on override discount rule scope are invalid
User enters scope_no "13" but plan or service not provided	15021 - Plans on override discount rule scope can not be blank 15023 - Services on override discount rule scope can not be blank
User enters scope_no "13" but plan and service are invalid	15022 - Plans on override discount rule scope are invalid 15024 - Services on override discount rule scope are invalid

General information on discount rules in Aria can be found here.

---

Selected Aria APIs Updated with <client_sku> Input/Output Field (DEV-10555)

Aria now provides for more efficient billing of non-subscription offerings (inventory items) by standardizing the use of the input/output field designating the inventory item. With this feature, the <client_sku> field will now be included in the Aria APIs noted below and the existing <client_item_id> input/output field will be deprecated.

This applies for the following categories:

Category 1

The following APIs have been enhanced to accept <client_sku> as an alternate input parameter:

API	Added Parameter Name	Deprecated Parameter Name
get_client_item_classes_m	<filter_client_sku>	<filter_client_item_id>
get_client_item_images_m	<client_sku>	<client_item_id>
get_client_item_supp_fields_m	<filter_client_sku>	<filter_client_item_id>
get_client_items_basic_m	<filter_client_sku>	<filter_client_item_id>
get_client_items_all_m	<filter_client_sku>	<filter_client_item_id>
get_client_item_prices_m	<filter_client_sku>	<filter_client_item_id>

API	Added Parameter Name	Deprecated Parameter Name
update_inventory_item_m	<existing_client_sku>	<client_item_id>
get_inventory_item_details_m	<client_sku>	<client_item_id>
create_discount_rule_m	<item[]> <client_sku>	<item[]> <client_item_id>
create_coupon_m	<discount_rule[]> <item[]> <client_sku>	<discount_rule[]> <item[]> <client_item_id>
update_coupon_m	<discount_rule[]> <item[]> <client_sku>	<discount_rule[]> <item[]> <client_item_id>
create_surcharge_m	<client_sku[]>	<client_item_id[]>
edit_surcharge_m	<client_sku[]>	<client_item_id[]>

Category 2

The following APIs have been enhanced to return <client_sku> as an alternate output parameter:

 

API	Added Parameter Name	Deprecated Parameter Name
get_discount_rule_details_m	<rule_application> <client_sku>	<rule_application> <client_item_id[]>
get_coupon_details_m	<discount_rule[]> <rule_application> <client_sku>	<discount_rule[]> <rule_application> <client_item_id[]>
get_surcharge_details_m	<client_sku[]>	<client_item_id[]>

Category 3

The <client_item_id> input parameter has been deprecated for the following API:

API	Deprecated Parameter Name
create_inventory_item_m	<client_item_id>

Category 4

The <client_item_id> output parameter has been deprecated for the following APIs:

API	Deprecated Parameter Name
get_client_items_all_m	<all_client_item_details> <client_item_id>
get_client_items_basic_m	<items_basic_details> <client_item_id>
get_items_by_class_m	<class_items> <client_item_id>
get_items_by_supp_field_m	<items_by_supp_field> <client_item_id>
gen_rb_m	<invoice_items> <client_item_id>
create_cm_m	<cm_details> <client_item_id_out>
get_cm_details_m	<cm_line_details> <client_item_id>
get_invoice_cm_details_m	<invoice_cm_line_details> <client_item_id>
get_invoice_details_m	<invoice_line_details> <client_item_id>
gen_invoice_m	<out_invoices_list> <invoice_items> <client_item_id>
update_acct_plan_multi_m	<invoice_items_details> <client_item_id>

 

API	Deprecated Parameter Name
get_inventory_items_m	<inventory_items> <client_item_id>
get_inventory_item_details_m	<client_item_id>

The following error code has also been added for these APIs:

Error Code	Description
3109	Invalid Client SKU

---

Remainder Discount Rule Parameter for Prorating Fixed Discounts (DEV-10593)

To support new Remainder Discount Rules for fixed amount discounts using Aria APIs, a <remainder_discount_rule_indicator> input parameter was added to create_discount_rule_m, create_coupon_m and update_coupon_m. When set as TRUE (1), this argument will prorate the discount applied on the initial invoice and apply the remaining proportion of the discount on the appropriate invoice. By default its value is "null".

---

XML Statement Number Now Included As Input/Output Fields for Selected APIs (DEV-10611)

In an effort to make it easier to retrieve the XML statement number as part of statement processing, Aria now allows the get_aria_xml_statement_m API to accept <statement_no> as an alternate input to the <xml_statement_no> field. Additionally, the get_acct_statement_history_m API now returns the <xml_statement_no> in the API response.

---

API Fixes 

• The <bill_email> output parameter in the get_account_details_m API will now return the email address associated with the billing group. (TICKET-18780)
• When cancelling a plan via update_acct_plan_multi_m which is billed with both charge and tax lines using the Vertex tax engine, the service credit now calculates the correct prorated credit amount for the tax-inclusive service based on the remaining days before the next bill date. (TICKET-18827)