Dynamic pricing changes a price according to a rule, but raising a plan’s price and charging for usage are not necessarily the same model. Before selecting tools, define which variable changes the price and when the customer learns the amount.
Separate three models
| Model | What changes | Fictional example |
|---|---|---|
| Fixed plans | Included service by tier | Basic and advanced plans at published prices |
| Usage-based pricing | Amount based on consumption | A price per recorded request |
| Dynamic pricing | Price based on a contextual rule | An offer priced for a defined time slot |
For service tiers, see preparing subscription plans. For consumption-based amounts, read usage-based billing.
Make the rule traceable
Keep the input, rule version, calculated price and time of the offer. Define limits and behaviour when information is missing. A variable calculation does not need to be described as artificial intelligence.
In a fictional example, an offer is priced at €15 under rule A. If the rule changes later, the system should retain what the buyer saw and accepted. Recalculating without that record makes the charge difficult to explain.
Connect the offer to renewal
Decide whether the price applies to one purchase, the next period or future periods. Explain the mechanism and review applicable terms before changing charges. Subscription signup should not be interpreted as permission for any later amount change.
The sequence is: rule → recorded price → customer information → payment operation. The gateway receives an amount; deciding what that amount should be requires separate logic.
When should you keep things simpler?
If you cannot explain the rule or reconstruct an amount, it is not ready. Fixed plans may be enough while you clarify the need. Complexity should solve a real problem in the offer.
Before implementation, check that the tools support the calculation and that tests cover limits, missing information and rule-version changes.