Offer Life Cycle Execution

The elements in an offer life cycle are executed in a specific order. For example, an offer life cycle might define the following:

  1. An offer is in status Pre-Active. This status has a transition to status Active configured with the following configured:
    • MtxStatusConditionActivate condition
    • MtxStatusActionFeeCharge action
  2. When a usage event occurs, the system checks to see if any transition in the current status has a MtxStatusConditionActivate condition configured. Once the system determines that the condition exists and has been met and all filters have passed, the status object transitions to status Active. The condition and its filters are evaluated using the current status before the transition.
  3. Once the transition has occurred, the system checks if any actions can be executed and if the execution is allowed. Actions are executed when all filters pass and the new status allows that action. (For example, you cannot cancel an offer if the new status does not allow that action.) The action and its filters are evaluated after the transition using the new status.

    The system finds that the MtxStatusActionFeeCharge action can be executed and all its relevant filters have passed. Therefore, a fee is applied to the fee debt balance.

    Note: The status transition remains regardless of whether the actions pass or fail (assuming they are allowed).
  4. If the executed action results in a new condition being met, that condition is processed separately.
Status transitions due to MtxStatusConditionRecurringFailure and MtxStatusConditionRecurringSuccess are performed in the same transaction in which recurring processing occurs, and the offer status is updated instantaneously.
  • The PurchaseOffer, Recharge, Payment, and PaymentRefund APIs perform recurring processing and status transitions at the end of the operation.
    Note: The AdjustBalance API does not perform recurring processing as the AdjustBalance API is an administrative API to update balances.

    When a top-up offer is purchased or when making a recharge, payment, or payment refund request, recurring processing is triggered and offer status transitions are performed based on the results of recurring processing.

  • At the beginning of processing a SubMan request, when retrieving the offer, recurring processing is performed first, followed by status transitions.

    When a SubMan request triggers recurring processing, offer status transitions are performed based on the results of recurring processing.

For more information about the MtxStatusConditionRecurringFailure and MtxStatusConditionRecurringSuccess conditions, see the discussion about offer life cycle conditions.