Concepts and Features #

Pricing Instances #

Pricing instances are abstractions that help with grouping related metadata, products and items together, each product and item is unique within an instance. Instances are completely separate, it is never possible to refer to properties of another instance from within an instance.

DynamO Pricing also calculates and sends prices for each instance separately.

Pricing instances are typically used to represent sales intervals or ongoing real-life events. The following are good examples of what a pricing instance could be:

• ticket sales before a theatre performance
• ticket sales for a music festival
• ticket sales for a single online event

However the DynamO Pricing engine does not have any constraints on the time interval of a pricing instance, the following are also good examples:

• pricing of offices for rent
• pricing of parking lot spots

We try not to limit how pricing instances could be used, they do not even have to refer to real-life events, any other scenarios can be applied as long as they fit the architecture of the DynamO Pricing system.

Entries #

Almost all interactions with instances happens via instance entries. Each instance has its own immutable entry log where each new entry must always be newer than all the previously added entries. Entries also cannot be removed and new entries must be submitted if changes are desired instead.

This architecture helps us maintain the credibility of our pricing algorithms and services while making audits easier.

For a list of available entry types visit the API documentation.

Products and Items #

DynamO Pricing supports the most commonly used two-level hierarchy. Products are the entities that can be sold and reserved, products must have some capacity that determine how much of each of them can be sold.

Products alone do not have a price. Items (price types or price points) are the entities that specify prices for products. A product may have multiple items associated with it, whereas an item is always specific to a product. When recording sales or reservations both the product and the item must be specified.

Items support various properties, such as different price ranges and sales periods (e.g. for early bird tickets).

Here are the some commonly used equivalent terms for products and items we have seen outside DynamO Pricing:

The naming for item is unfortunate however we cannot change it for historical reasons.

Examples #

Music Festival #

• Product: Music Festival Ticket (capacity: 1000)
  • Item: Early Bird (price: 100)
  • Item: Regular (price: 150)
  • Item: VIP (price: 200)

Theatre Performance #

• Product: Front Row (capacity: 500)
  • Item: Front Row Adult (price: 100)
  • Item: Front Row Child (price: 50)
• Product: Back Row (capacity: 1000)
  • Item: Back Row Adult (price: 50)
  • Item: Back Row Child (price: 25)
• Product: Balcony (capacity: 200)
  • Item: Balcony Adult (price: 75)
  • Item: Balcony Child (price: 35)

Note that in case there are more than one products, they must never overlap in terms of capacity.

Pricing Models #

No two instances are the same, and no two instances can be priced the same way optimally. We define pricing models for pricing algorithms that behave differently given the same scenario, have different pricing strategies and vary in terms of need for external information.

Each pricing model might need further configuration and expose knobs for fine-tuned external prices.

The default pricing model accepts only the essential configuration properties and will always try to match the best possible algorithm and strategy for a given instance based on the available information.

Pricing Workflow #

After understanding the above concepts, the dynamic pricing process itself is relatively simple. After creating and setting up a pricing instance, entries should be sent and the pricing engine will periodically send prices back. An example walkthrough through the REST API can be seen here.

Security #

The DynamO Pricing API offers various features to ensure safe and secure use of our services.

We require TLS encryption for the entire surface of our exposed API servers.

We use a certified implementation of the well-known oauth2 protocol. The authentication tokens are short-lived to minimize the risk in case of leakages or MITM attack attempts.

Each pricing subscription requires a token to be set that is used to authenticate the DynamO Pricing engine during callbacks. TLS client-side certificate authentication is also possible, however we do not have this exposed in the API, if you wish to use this feature, please contact us.

Entries can be made tamper-proof to ensure that no one, not even us can modify entries after they have been submitted. Each entry can be sent in a signed JWT format (RFC7519) after sharing the public key with DynamO Pricing that can be used to verify the entry.