Refunding Failed One-Time Events

One-time events that are not delivered successfully can use the 3GPP Refund Account principle to remove the balance impacts associated with the charge.

Note: When using the process described here, balance impacts are reverted in-full. Amounts different from those stored in the database cannot be refunded. For information about refunds using the RFC4006 Refund Account principle in which the REFUND_ACCOUNT CCR includes a Request-Service-Unit AVP indicating a specific number of units to be refunded, see the discussion about refunding using a unit value.

If a Requested-Service-Unit AVP of a DIRECT_DEBITING CCR is successfully authorized, the Refund-Information is included in the CCA and the balance impacts are stored to the MATRIXX in-memory database. Subsequently, if a client sends a one-time event message REFUND_ACCOUNT CCR with the Refund-Information that was included in the CCA, the balance impacts are refunded. MATRIXX Charging Application provides the quota and cost information in the Cost-Information and Granted-Service-Unit AVPs in the REFUND CCA message.

One-time events use the 3GPP model in which all rating is performed using Multiple-Services-Credit-Control (MSCC). For more information about one-time events, see the discussion about rating one-time events.

Refunding one-time events refunds a debit quantity (including any applied taxes) to G/L and non-G/L balances, and does not revert any of the various direct effects or side effects of the related debit operation. This includes impact to virtual balances or meters, creation of on-demand balance periods, first usage of a balance, life cycle status transitions, and notification delivery. If the original charge is initiated by a group member, the refund is credited to the root group balance. Virtual balances are not refunded.

Note: The tax recognition type for failed one-time events is always immediate.

For information about taxes, see the discussion about taxes.

A failed one-time event cannot be refunded after the refund expiration date, which is configurable with the following create_config.info question. The default value is 86400 (one day).

Global:How long (in seconds) should EVENT_REQUEST records be retained before being purged from the system?

Important: MSCC is optional in RFC 4006 but required in 3GPP, with the following ramifications:

3GPP places AVP Refund-Information under MSCC. To use this AVP with MATRIXX, customers not using MSCC must create a diameter_dictionary_base_xml_sed.extra file to add the AVP, MDC field mapping, and condition to the Diameter Dictionary. For example, the file should map the following information:
```
avp name="Refund-Information" 
mdc_field_name="MultiServiceList.RefundInfo"
condition_name="RequestDoesNotSupportMultiService"
```
Each DEBIT MSCC is assigned its own Refund-Information ID to be refunded independently of the others.

MATRIXX Charging Application supports a non-3GPP enhancement in which a network-supplied (such as SMSC or MMSC) submission charge CCR AVP can be used as the transaction reference in the CCA and CCR Refund-Information AVPs. Configuration of this non-3GPP enhancement is dependent upon your specific requirements, but you must ensure that the refund information in the CCR is mapped to the MultiServiceList.RefundInfo field so that MATRIXX Charging Application knows that it should use this string in the CCA instead of the auto-generated string that it normally generates.

For information about configuring the length of time to keep EVENT_REQUEST records, see the discussion about global system configuration MATRIXX Configuration. For information about customizing the Diameter Dictionary and Diameter Credit-Control command, see MATRIXX Diameter Integration.