Pricing Module

The Pricing Module is a centralized billing and configuration engine responsible for defining pricing structures, executing charge calculations, subscribe able Plans , and managing optional Add on.

It enables organizations to support:

• Usage-based billing
• Dynamic pricing
• Tiered charging
• Event-based rating
• Optional feature Add on
• Enterprise billing workflows
• Attribute-based pricing visibility and access control

Rate List

Rate Lists define the pricing structure used by the billing engine to calculate charges.

They support configurable pricing models that can adapt to multiple business scenarios including:

• recurring billing
• usage charging
• slab pricing
• volume-based pricing
• event-driven calculations
• dynamic pricing formulas

Charges Rules

Charge Rules define how billing calculations are executed.

They process usage events, evaluate conditions, and generate invoiceable charges based on configured pricing models.

• Formula Evaluation
• Usage Rating
• Threshold Handling
• Event Processing
• Conditional Charging
• Dynamic Billing

Plans

Plans define subscription offerings available to customers.

A plan combines pricing, services, quotas, billing cycles, and commercial rules into a subscription package.

Subscription-based pricing models are commonly used to provide structured commercial offerings such as Basic, Premium, and Enterprise plans\

Base Plans

Base Plans represent the primary subscription foundation assigned to customers.

They define the default commercial structure that includes:

• core services
• recurring charges
• included quotas
• billing frequency
• primary pricing model

Additional features and optional services can later be attached through Add-ons.

Add-ons

Add-ons provide optional service extensions that enhance customer subscriptions.

They allow organizations to monetize additional features independently from the primary subscription plan.

Enterprise billing systems commonly support optional recurring or one-time extensions attached to subscription offerings.

• Feature Expansion
• Recurring Add-ons
• One-Time Charges
• Usage Extensions
• Premium Features
• Flexible Assignment

Attribute-Based Access Control (ABAC)

The platform implements a centralized Attribute-Based Access Control (ABAC) framework using Security Attributes to control visibility and access across pricing, subscription, customer, and operational entities.

Security Attributes provide fine-grained authorization by evaluating whether a user’s assigned attributes match the security configuration of a resource.

This enables secure and scalable access control across enterprise environments without relying solely on static role-based permissions.

Security filtering can be applied across:

• rate lists
• charge rules
• plans
• base plans
• add-ons

Purpose of Security Attributes

Security Attributes are designed to provide:

• multi-dimensional access control
• tenant-level data isolation
• region-based visibility restrictions
• controlled pricing visibility
• secure subscription access
• enterprise-grade authorization governance

The framework ensures users can only access resources aligned with their assigned business dimensions.

Core Security Model

The ABAC framework evaluates access using two primary components:

Component	Description
Subject Attributes	Attributes assigned to authenticated users
Resource Attributes	Attributes assigned to entities/resources

Access is granted only when the subject’s attributes satisfy the resource’s security requirements.

Security Matching Logic

The ABAC engine evaluates access using multi-dimensional attribute matching.

OR Logic Within a Dimension

If multiple values exist inside the same dimension, any overlapping value grants eligibility for that dimension.

Example

region = north OR east

If the user belongs to either north or east, the dimension passes validation.

AND Logic Across Dimensions

All configured dimensions must match simultaneously for access to be granted.

Example

region match
AND
department match
AND
tier match

Failure in any dimension results in access denial.

Authorization Evaluation Example

User Attributes\

Resource Attributes

region = north,south
department=sales

Authorization Result

Access Granted

Because:

• region overlaps (north)\
• department overlaps (sales)\

Administrative Access

Administrative users bypass Security Attribute filtering entirely.

Administrative access provides unrestricted visibility across: