Deferred Payment Settlements

When you purchase a catalog item with Pay Now, you can specify that MATRIXX Charging Application does not request the payment settlement immediately. This may be necessary, for example, due to regulatory requirements for payment settlements.

When using Pay Now for a non-deferred payment settlement, a payment authorization is requested at the time of the purchase and the payment settlement is automatically completed after the purchase (either immediately following the purchase or at a pre-configured time of day).

When the payment settlement is deferred, the purchase response includes a payment identifier (PaymentResourceId), which you can use subsequently in a payment settlement request to identify the purchase.

The following restrictions apply to deferred settlements:
  • The purchased catalog item must reference either a one time offer or a one time bundle.
  • The component in the product offers referenced by the catalog item must be a charge or a discount. The product offer cannot include any other type of component (such as a grant or balance state update).
  • The product offers referenced by the catalog item cannot contain a required balance.
  • You cannot split payments between a main balance and Pay Now. The entire payment must be a Pay Now payment.
  • A transaction that includes a purchase with a Pay Now deferred payment settlement cannot include other Pay Now requests that are not for deferred settlements. However, you can request multiple purchases with deferred settlements in a single operation. If settlement timeouts and timeout actions are specified in the purchase, they must be the same for all purchases in the transaction. If the settlement request fails, MATRIXX Charging Application does not retry the request.
    Note: The deferred settlement timeout (DeferredSettlementTimeout) cannot be greater than the payment expiration time.
  • Life cycle status policies are not checked for payment settlement operations. If the policies for the status at purchase time allow the purchase, subsequent changes to the life cycle status do not prevent the payment settlement.

Pay Now Timeouts

A timeout for a Pay Now operation, and whether to retry an operation if the Payment Service reports a transient failure, depends on whether the operation is invoked through the SubMan APIs or is system initiated. When invoked through a SubMan API, the timeout is short and there are no retries. The client gets an immediate response that the operation failed and can retry. For system-initiated Pay Now operations, the timeout can be much longer and the operation can be retried if the Payment Service reports a transient failure.

Deferred Settlement Timeouts

During MATRIXX Engine configuration, you can configure the default timeout in hours and the timeout action if the settlement times out (void or settle). For information about configuring the deferred settlement timeout and the deferred settlement timeout action, see the discussion about MATRIXX Engine configuration.

At purchase time, you can override MATRIXX Engine configuration defaults by specifying the amount of time in hours to wait after which a payment settlement times out in the MtxChargeMethodData MDC DeferredSettlementTimeout field. You specify whether to settle the payment or void the transaction after a timeout in the MtxChargeMethodData MDC DeferredSettlementTimeoutAction field. For more information, see the discussion about Pay Now payments and recharges.

Voiding Payment Settlements

At any time after a purchase, but before requesting a settlement and before the timeout, a client can void a payment authorization with a subscriber or group refund payment request. If a payment authorization is voided, either through a timeout or by the client invoking the payment refund request, MATRIXX Charging Application generates a payment refund event and a payment event. If the payment authorization is voided because of a deferred settlement timeout, the Reason field in the resulting refund event is Deferred Settlement timeout.

General Ledger

If MATRIXX Engine is configured to include General Ledger (GL) information in events, when the purchase request defers the payment settlement, the purchase event indicates a deferred settlement so that the GL processor does not recognize the revenue for the purchase charges immediately. Instead, the GL processor recognizes the revenue for purchase charges at settlement time.

The revenue recognition type (RevenueRecognitionType) in the MtxEventGLInfo MDC for deferred settlement charges, discounts, and taxes is 6 (pending_settlement). GL information in purchase events with revenue recognition type 6 is processed after the authorized Pay Now payment is settled. As a result, some journal entries for revenue and tax are generated at payment settlement time, not purchase time. Refund events for a purchase charge with a deferred settlement do not include GL information if the refund is requested before the authorized Pay Now payment is settled.

When true, the DeferredSettlement boolean field in the payment settlement EDR (MtxPaymentSettlementEvent) indicates that the payment settlement is not automatically invoked and is initiated by the client requests.

For more information about General Ledger processing, see the discussion about General Ledger records in MATRIXX Integration.

Revenue Recognition

When revenue recognition is not consumption based, the revenue for purchase charges is recognized on the day of purchase. For more information about revenue recognition, see the discussion about recognizing revenue in MATRIXX Integration.

SubMan APIs

Use the following APIs to request a payment settlement:
  • REST
    • Subscriber: /subscriber/{SearchTerm}/settle_payment/{ResourceId}
    • Group: /group/{SearchTerm}/settle_payment/{ResourceId}
  • SubMan
    • MtxRequestSubscriberSettlePayment
    • MtxRequestGroupSettlePayment

These requests fail if the ResourceId does not identify a purchase in which a deferred settlement was specified.

The payment history API responses include a field (IsDeferredSettlement) for each payment that indicates if a deferred settlement was requested and if the settlement is still pending (not settled or voided). A payment settlement operation can be applied only to deferred payments that have not been settled or voided. For more information about the payment_history APIs, see MATRIXX Subscriber Management API.

MATRIXX Engine Configuration

You can configure how long the Payment Service defers the payment settlement and the action to take if this timeout is triggered before a payment settlement or a payment refund is requested. These values are used if the timeout and timeout action are not specified in the purchase. The deferred settlement timeout cannot be longer than the payment data expiration time.
Note: If the default settlement timeout is longer than the payment expiration time, the default deferred settlement timeout is reduced to the payment expiration time, and an error message is logged. If a deferred settlement timeout is specified in the purchase operation that is longer than the payment expiration time, the purchase request is rejected, an error is logged, and the transaction is aborted.

For more information about Pay Now MATRIXX Engine configuration, see the discussion about MATRIXX Engine configuration.