Pricing rules allow you to package and bundle your product in completely unique ways and provides you extreme flexibility to monetize as you see fit. This is an advanced rule engine that can be used to apply different rules on existing rate cards in an invoice or other static/dynamic fields and apply a computed logic while you generate an Invoice.
Configurability of pricing rules
Pricing rules in Togai are configurable using supported javascript operators. Computation of a pricing rule happens along with the computation of the invoice (near real-time). The following entities should be defined for a pricing rule.
usage.
or revenue.
You cannot apply conditions, computations or update In Advance rate cards currently.Currently, you can use the below variables from the price plan to create conditions and computations in a pricing rule:
You can use the below logical and mathematical operators on the above variables while creating a pricing rule condition/computation:
Let’s take the case of a payment processor like Stripe. Stripe’s pricing model is based on the transaction amount and their default pricing is 2.9% of the transaction amount + 30 cents per transaction. For simplicity, let’s assume Stripe’s default pricing is 3%.
Now, they have a custom contract with a large enterprise which follows the below pricing -
In this case, we model the 3 separate payment modes as 3 individual usage meters and usage rate cards in Togai. The aggregated volume discount is configured as a pricing rule as per the below logic -
Rule - Total payment value (recorded as a usage meter) of rate card 1 + rate card 2 + rate card 3 > $1mn
Computation - 10% of total invoice value
Add/update - Add as a discount to the invoice
Another example - we have a cloud contact center solution that offers license based pricing based on the number of call center agents using their product. However, they also provide a tele-calling facility which is priced based on the number of minutes.
Let’s add a complex scenario where the company wants to provide a bundled offering where each license gets a free call usage of upto 1000 minutes per month and beyond that, there is an overage price.
In this case, we have 2 individual rate cards to model the license fees with number of licenses as input quantity and the usage based rate card for the tele-calling fees. For the bundled pricing, we create the below rule
Rule - Usage quantity of tele-calling > 0
Computation - Minimum of [(Number of licenses * 1000 * price per unit of a call) , Actual tele-calling usage revenue]
Add/update - Add as a discount to the invoice
Pricing rules allow you to package and bundle your product in completely unique ways and provides you extreme flexibility to monetize as you see fit. This is an advanced rule engine that can be used to apply different rules on existing rate cards in an invoice or other static/dynamic fields and apply a computed logic while you generate an Invoice.
Configurability of pricing rules
Pricing rules in Togai are configurable using supported javascript operators. Computation of a pricing rule happens along with the computation of the invoice (near real-time). The following entities should be defined for a pricing rule.
usage.
or revenue.
You cannot apply conditions, computations or update In Advance rate cards currently.Currently, you can use the below variables from the price plan to create conditions and computations in a pricing rule:
You can use the below logical and mathematical operators on the above variables while creating a pricing rule condition/computation:
Let’s take the case of a payment processor like Stripe. Stripe’s pricing model is based on the transaction amount and their default pricing is 2.9% of the transaction amount + 30 cents per transaction. For simplicity, let’s assume Stripe’s default pricing is 3%.
Now, they have a custom contract with a large enterprise which follows the below pricing -
In this case, we model the 3 separate payment modes as 3 individual usage meters and usage rate cards in Togai. The aggregated volume discount is configured as a pricing rule as per the below logic -
Rule - Total payment value (recorded as a usage meter) of rate card 1 + rate card 2 + rate card 3 > $1mn
Computation - 10% of total invoice value
Add/update - Add as a discount to the invoice
Another example - we have a cloud contact center solution that offers license based pricing based on the number of call center agents using their product. However, they also provide a tele-calling facility which is priced based on the number of minutes.
Let’s add a complex scenario where the company wants to provide a bundled offering where each license gets a free call usage of upto 1000 minutes per month and beyond that, there is an overage price.
In this case, we have 2 individual rate cards to model the license fees with number of licenses as input quantity and the usage based rate card for the tele-calling fees. For the bundled pricing, we create the below rule
Rule - Usage quantity of tele-calling > 0
Computation - Minimum of [(Number of licenses * 1000 * price per unit of a call) , Actual tele-calling usage revenue]
Add/update - Add as a discount to the invoice