Release 51

Revenue Recognition for Partial-Pay Invoices (DEV-10400)

If the client parameter “Use Revenue Recognition Profile Partial Pay Logic” is set to True, you can use Aria Billing Cloud to recognize revenue for partially paid invoices. Aria’s Revenue Recognition provides a representation of account activity to ensure a meaningful and consistent measurement of business performance. Please note: An existing hidden parameter may need to be configured to enable this functionality; contact your Aria representative for more information.

Open Invoice Charge/Credit Tax-Inclusive Modification (DEV-10558)

Aria has modified its proration calculation logic to address a rounding issue for open invoice proration charges/credits using a tax-inclusive service. To enable this feature, the Aria Internal Tax Rounding Preference needs to be set to Natural Rounding (Configuration > Billing > Taxation Settings).

Payment Method Name, ID and Description Now Included For All Payment Methods (DEV-10997)

The Payment Method Name, Client-Defined Payment Method Id, and Payment Method Description fields have been added for all Aria payment methods at the time of account creation to provide a consistent level of payment method details. These fields currently exist for the Tokenized Credit Card (TCC) and Tokenized ACH (TACH) payment methods (Accounts > [search for account] > Account Overview > Payment Methods).

Smart Payment Support For Klarna and Sofort with Adyen and TCC Support with Stripe (DEV-11044)

The Stripe payment processor is now integrated as part of Aria’s smart payments with this release for the Tokenized Credit Card payment method (pay method 13). The following transactions are supported with this integration: capture, payment, and create/query token.

The following card types are supported:

• American Express
• Diners Club International
• Discover
• Japan Credit Bureau (JCB)
• Mastercard
• UnionPay
• Visa

For tokens created in Aria, the token/agreement_id is stored in the format “payment_method_id:customer_id” in Aria. For tokens created outside of Aria, you should create both the payment method ID and customer ID and combine them (payment_method_id:customer_id) in the “bill_agreement_id” field. If either the ID is missing or the token is not in a valid format when attempting to process a payment, Aria will generate an error saying "Invalid token. The valid token format is payment_method_id:customer_id."

Learn more about the Stripe payment gateway from here.

Usage Accumulation Data Now Available for Customer Statements (DEV-11080)

This feature introduces the ability to display usage accumulation data on self-invoicing customers' statements (prn_pi_service_usage_accumulation). This information will include usage units for all active plan instances of the MPI for which the usage accumulation feature is "Enabled".

With this feature, two different totals are now available to be displayed: pre-accumulated units of prior periods, and the sum of "pre-accumulated units of prior periods + unbilled usage units of period (till date if any)".

Contact Customer Support if you want to include this on your statement template. The following data is available for displaying on statements with this feature:

Braintree Merchant Account ID Field Now 32 Characters (DEV-11082)

The Braintree Merchant Account ID field has been expanded to 32 characters at the payment gateway and collection group levels to support a back-end Aria configuration (Configuration > Payments > Payment Gateways/Collection Groups). In the event of Merchant Account ID settings at both the payment gateway and collection group levels, the collection group setting takes precedence.

Application Fixes 

• When replacing a Plan with configuration to rollover to another plan after a certain period of time, the "current date” or “plan replacement date" is used as the date for Rollover Change Date calculation. Previously when a Plan was replaced and configured to rollover at the same time, the Plan Rollover Effective Date was calculated incorrectly resulting in the rollover occurring immediately instead of after the allotted amount of time. (TICKET-15249)
• The logical condition for the surcharge calculation has been modified to correctly apply fixed surcharges on Invoices when an Account has two MPI’s during Account creation and the second MPI is mapped with a fixed surcharge. Previously, the fixed surcharge was missing on the Invoice for the second MPI. (TICKET-18873)
• When creating or editing a Plan with Admintool APIs the Account Rollover Status is now set and displayed correctly. This Account Subscription status can be seen in the Action Detail field within the Future Plan Changes tab (Accounts > [search for an account] > Plans > Future Plan Changes). (TICKET-19029)
• The account balance is no longer wrongly calculated and displayed on the Account Overview screen when an invoice is generated with negative total (i.e. debit amount < credit amount). Previously, certain third-party tax engines would incorrectly return such a -$0.01 total as $0.01. (TICKET-19049)
• You can now discard and recalculate pending invoices of parent accounts in the Aria UI via Configuration > Billing > Pending Invoices, when its child accounts with parent-pay MPIs have pending invoices that are yet to be approved. The system still prevents you from approving such pending invoices and returns an error if you attempt that action. (TICKET-19057)
• The tooltip message when closing a Contract from the "Cancel/Terminate Contract" UI screen has been updated to clarify that no cancellation fee will be charged when a multi-plan Contract is cancelled before the contract’s completion date. The tooltip message now reads: “The contract is being closed at the request of the account holder. No early cancellation fee will be assessed against the account holder, even if an early cancellation fee is specified by this contract.” (TICKET-19064)
• MPIs payed via Payment Terms now enter into a dunning status when the Aria daily batch process detects that they have an overdue balance. (TICKET-19076) 
• When sending a universal contract notification via Email, only one contract notification is sent, not a notification for each plan in the universal contract. Also, plan names are no longer included in universal contract notifications. (TICKET-19077)
• A timestamp discrepancy between events and payments has been resolved by modifying the code that determines the database session time zone to ensure it updates to the client configured time zone after each connection reset. (TICKET-19087)

Input Field Precedence Honored and Performance Improved for get_client_plans_all_m (DEV-10956)

This feature updates the behavior of the API Call get_client_plans_all_m. Now, the fields <client_parent_plan_id> and <client_plan_id> will supercede any values passed in the <parent_plan_no> and <plan_no> fields. Also, if invalid inputs for the fields <acct_no> or <client_acct_id> are passed, the return value for the <all_client_plan_dtls> array will be empty. Previously, all plans in your Aria instance were returned.

Added ability to create contracts in the past provided that they do not end prior to or on the current date (DEV-11014)

The following APIs now have the added ability to create contracts with a Start Date in the past provided that their End Date is not set to the current date or earlier. These are: create_acct_complete_m; create_acct_universal_contract_m; create_instance_contract_m; modify_acct_universal_contract_m; and modify_instance_contract_m. A new error message displays if the contract End Date is not set correctly. Also, a new output parameter <plan_instance_create_date> in the get_acct_plans_all_m API response will return the creation date of the plan instance.

Smart Payment Support For Klarna and Sofort with Adyen and TCC Support with Stripe (DEV-11044)

As part of Adyen's Smart Payments integration for this release, the Klarna pay method is now supported. This is an alternate payment method (APM) where the initial Klarna Pay Later payment will happen outside Aria. After the successful initial payment, the client will use the record_alternate_payment_method_m API (pay_method = 42) to record their initial payment with Aria, with which a Klarna token is created and used for recurring payments with pay_method = 43. Aria support full/partial refund flow for both Klarna payments and tokenized Klarna payments.

Note: Aria rounds off the VAT percentage when making a Tokenized payment with the Klarna pay method as Adyen supports rounding up to 2 decimal places.

With this release, the APM payment method "ApplePay - Indirect" is now supported for the Adyen payment processor (pay_method=38).

The Apple Pay workflow is as follows:

1. Perform an ApplePay payment authorization outside of Aria (using a unique shopperReference that should be communicated to Aria and recorded against an account via the input in the record_alternative_payment_m Aria API).
2. Aria will then perform a capture against the provided pspReference (from Adyen’s authorization response).
3. Once Aria receives the capture webhook notification, the payment transaction will be created in Aria and applied against the provided in the record_alternate_payment_m API.
4. Once the ApplePay payment recorded, we (Aria) query the token details from Adyen using the shopperReference (provided in the input field) which is associated with the initial ApplePay payment.
5. Also, a new billing_info sequence for the "Tokenized ApplePay" payment method will be created in Aria along with the token details (this billing_info sequence will be used for subsequent or recurring transactions).

Adyen’s Smart Payments integration now also supports the Sofort APM. Sofort is a single use, delayed notification payment method that requires customers to authenticate their payments. It is a popular online banking payment method in Europe with high usage in Germany, Austria, Switzerland, and Belgium.

After the successful initial payment outside Aria, use the record_alternate_payment_m API (pay_method = 36) to record the initial payment with Aria, with which Aria creates a SEPA token (pay_method = 37) to be used for recurring payments. Aria supports full/partial refunds for both Sofort payments and tokenized SEPA payments.

Learn more about the Adyen payment gateway from here.

API Fixes 

• When replacing a Plan with configuration to rollover to another plan after a certain period of time via replace_acct_plan_m API, the "current date” or “plan replacement date" is used as the date for Rollover Change Date calculation. Previously when a Plan was replaced and configured to rollover at the same time, the Plan Rollover Effective Date was calculated incorrectly resulting in the rollover occurring immediately instead of after the allotted amount of time. (TICKET-15249)
• The <alt_proration_start_date> field value is now honored for both Master and Supplemental Plans when they are replaced via calls to update_acct_plan_multi_m. (TICKET-19042)
• Plan Instances queued for anniversary status update via the update_acct_plan_multi_m API were previously displaying an incorrect Effective Date. A new global variable has been created to correctly store the queued change date with the offset interval considered. This change results in the correct Effective Date displaying within the UI. (TICKET-19074)
• The code that triggers the event 'Account Administrative Contact Modified' has been altered to restrict triggering of the event so that it only occurs when the <acct_address_seq> field is updated via the update_acct_complete_m API. (TICKET-19090)

Object Query WSDL Files