Skip to main content

Pricing Configuration & Engine Versions

Kloyst uses a flexible pricing architecture with support for Meta rate adjustments, volume discounts, custom platform markup, and multi-tenant isolation.

🎛️ Pricing Configuration Models​

The database pricing configuration is divided into three main components:

1. Pricing Rates (PricingRate)​

  • Maps a template category (e.g., MARKETING) and billing region to a base rate.
  • Rates are stored in decimals to ensure accuracy on large campaigns.
  • Configurations support starting and ending dates (effectiveFrom and effectiveTo) to schedule pricing updates automatically.

2. Volume Tiers (PricingTier)​

  • Defines volume discounts based on the monthly count of messages sent.
  • Discounts are configured per template category.
  • Note: Per Meta policy, volume discounts apply only to UTILITY and AUTHENTICATION categories. The MARKETING category is excluded and always resolves to a 0% discount.

3. Platform Fee Rules (PlatformFeeRule)​

  • Defines Kloyst's platform markup added to Meta's base message rates.
  • Supported rule types:
    • PERCENTAGE: Adds a percentage-based markup (e.g., 25%).
    • FLAT: Adds a flat transaction fee.
    • HYBRID: Combines percentage and flat fees.
  • Scoped by vendor ID to allow for custom platform markups for enterprise accounts.

🏷️ Multi-Tenant Platform Fee Precedence​

Kloyst applies platform fee rules using a strict priority order:

  1. Vendor Custom Override: The engine looks for a platform rule specific to the vendor (vendorId).
  2. Global Default: If no override exists, the engine uses the global default rule where isDefault = true and vendorId IS NULL.
  3. Hardcoded Fallback: If no database rules are found, the engine uses a hardcoded fallback of 25% markup and logs a system warning.

🛡️ Estimation Engine Versioning​

The pricing engine uses a semantic versioning system (1.0.0) to track changes to the estimation logic:

  • All generated quotations and snapshots store the active estimationEngineVersion.
  • If pricing calculations or discounts are modified in the future, the engine version is bumped.
  • Versioning allows the system to support new pricing logic without breaking historical audit trails.