Attribute-Based Pricing in the Rating processor

Attribute-Based Pricing (ABP) in Mediation allows for dynamic pricing based on specific attributes, ensuring accurate charge calculations and integration into billing processes.

The Rating processor in Mediation supports Attribute-Based Pricing (ABP), as defined in the Pricing Catalog.

In the mediation layer, usage events are ingested with essential details such as the charge number, subscription number, attributes, and event date. These events are then processed by the Rating processor, which validates the subscription and charge information, checks alignment with the catalog’s attribute-based pricing configuration, and applies the defined rules to calculate the appropriate charge. Once the charge is determined, the operator returns accurate pricing information. If validations fail, error messages are displayed. All successfully rated usage flows downstream into the billing system, where it is integrated into invoicing and revenue processes.

Configuration considerations:

• Charge Type: Only Usage-based charges are supported. Recurring charges and One time charges types are not supported.

• Effective Date: Ensure that the charge’s Effective Date precedes the Event Date. You can configure the Effective Date within the product catalog.

• Rating Operator Configuration: Ensure that you provide both the Subscription Number and Charge Number values. These are required to correctly associate the charge during rating.

• Attributes: Only attributes with values are sent to Dynamic Pricing:

  • Empty strings are sent as ""
  • Missing or blank non-string values (like numbers, dates, booleans) are not sent at all.

Use pricing attributes with Negotiated Price Table pricing

Negotiated Price Table pricing can use non-usage attributes stored in RatePlanCharge.pricingAttributes together with usage attributes from the event.

To use these attributes in a Mediation meter:

• In the Enrichment processor, map RatePlanCharge.OriginalId to the CustomerReference event field.
• Map RatePlanCharge.PricingAttributes to an event field.
• Use an Advanced Transformer to extract the pricing attribute values required by the pricing table.
• In the Rating processor, map the subscription number, charge number, quantity, and any required pricing attribute fields.

The Rating processor uses the enriched event values to resolve the applicable price from the Product Catalog. Include every pricing attribute required by the Product Catalog configuration. If a required attribute is missing or no pricing-table row matches the supplied attributes, Mediation cannot resolve the intended price.

Example for attribute-based pricing

A telecom provider defines a usage-based charge in Zuora’s Pricing Catalog for mobile data consumption. The charge is configured with attribute-based pricing (ABP) using attributes such as Region and Network Type to differentiate pricing tiers. The charge’s Effective Date is set to January 1, 2025.

When a customer uses 2GB of mobile data on February 10, 2025, the mediation layer ingests a usage event with the following details:

• Subscription Number: S-100045
• Charge Number: C-200078
• Event Date: February 10, 2025
• Attributes: Region = “US-West”, Network Type = “5G”, Usage Quantity = 2GB

Rating Processor Flow

1. Validation:

   • Checks that the subscription number and charge number are valid.
   • Ensures the event date is after the charge’s effective date.

2. Attribute Handling:

   • Matches required attributes (e.g., Region, Network Type) with pricing configuration.

   • If an attribute is missing:

     • Only available attributes are sent.
     • Empty strings are sent as ""
     • Missing non-string values are ignored.

3. Pricing Application: Applies the correct pricing rule (e.g., 2GB on 5G in US-West).

Pricing Outcome

Pricing is calculated using the available attributes, or falls back to default pricing if no match is found. Returns an error if a required attribute is missing and pricing cannot be determined.

Event-level minimum and maximum behaviour

While using Dynamic Pricing, minimum and maximum amounts are applied per usage event. Each record is rated independently, and the result is tied to the tier’s configured limits. The system does not consolidate usage for the entire billing period before applying the minimum and maximum limits. This behavior can lead to higher-than-expected charges if multiple records trigger tier-level minimums or maximums. If the catalog configuration has the minimum and maximum defined, then the minimum and maximum amounts are applied per usage event.

Example:

Output

As the example shows, the system applies min/max values per record, not per billing period. Multiple records can each be lifted to their tier minimums, causing totals to exceed a single period-level minimum. No retroactive adjustment occurs when usage moves into a higher tier.