Recurring Processing

Recurring processing can be triggered when MATRIXX Task Manager sends a message to the Charging Server because a trigger time in a subscriber or group wallet is reached.

When processing the message, the Charging Server executes recurring processing on any cycle for which recurring processing has not been done. In addition, recurring processing can be triggered when a network or subscription management message is received. In this case, the Charging Server invokes pending recurring processing for the subscriber or group that is the target of the message.

The general order for recurring processing for a subscriber or group is:
  1. Purchased item cycles

    Cycle definitions are included in the subscription data, which includes information about the specific period boundary offset, the cycle state (such as recurring failure), and how the cycle is aligned (for example, with the balance cycle and the billing cycle).

  2. Balance cycle
    Note: You cannot control the order of processing of balance cycles. All the cycles of a subscriber or group are done before moving up to do recurring processing for a parent group.
  3. Billing cycle

All charges associated with a cycle are applied first, before any grants or rollovers. In addition, cycle processing occurs before any subscriber event processing. If a catalog item is purchased or canceled in the middle of a balance or billing cycle, the pricing is applied with any proration requirements. Recurring processing does not use product offers or bundles that have been canceled and for which the cancel end time has been reached. Pricing revisions are from the beginning of the cycle period, but the Charging Server does not use the product offer or bundle even if it was canceled after the start of the period.

For more information about external payment requests, see the discussion about balances with external payment requests.

When recurring charges are applied to balances associated with external payment requests, during recurring processing for purchased item cycles the external payment request records in the wallet are updated according to the following:
  • If no external payment request is found, an external payment request is generated. The payment due date is the greater of the recurring time and the PaymentDueDate in MtxPurchasedOffer.
  • If the external payment is due, recurring processing is successful and there is no additional action.
  • If the external payment is pending, the collected payment is processed, the balance is credited, the PaymentStatus is updated to paid, and an MtxExternalPaymentEvent is generated.

For more information about external payments, see the discussion about balances with external payments.

First-use charges and recurring processing are triggered by the G/L balance only. A subscriber or group virtual balance does not trigger first-use charges or recurring processing.

The RecurringFailureStatus field in the MtxWalletObject (bill cycles) and MtxPurchasedOffer (purchased item cycles) MDCs indicates if recurring processing succeeded in a cycle period on the first try. You can use this field in normalizations in bill cycle recurring components and purchased item cycle recurring components. You might want to use this normalization in a situation where you want to grant an additional amount or charge less if processing succeeds on the first try.

The RecurringFailureStatus field values are:
  • 0 — Recurring processing has not failed for the cycle on the first try.
  • Any other value — Recurring processing failed at least once for the cycle period (but not on the first try). Normalizers must not assume which nonzero value is used or make distinctions between different nonzero values.
Note: You cannot use this field for normalizations in balance cycle recurring components. In addition, normalizations with this field do not apply to cycle arrears recurring processing for a bill cycle because credit limits are ignored and processing does not fail. For more information about normalizers, see the discussion about normalizers.

For more information about recurring processing failure, see the discussion about recurring processing failure.

Recurring charges and grants applied during purchase or resumption of an offer are recorded in separate recurring events (MtxRecurringEvent).

For information about MtxRecurringEvent, see MATRIXX Integration.

The MATRIXX Charging Application does not try recurring processing for a cycle period after that period ends, even if a network message for usage in the preceding period is received. Recurring processing can be invoked for the current period of a cycle, even if recurring processing did not succeed for earlier periods. For information about recurring processing failures, see the discussion about recurring processing failures.

For information about configuring recurring processing, see the discussion about Task Manager configuration in MATRIXX Configuration.