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 #

We use two abstraction layers for describing objects that either have a price or can be sold. Products are the objects the pricing is based on, we observe how many "pieces of a product" we have, and adjust the prices accordingly.

Products alone do not have a price and cannot be sold, for that we define items, products and items are supposed to only exist together. Products can exist without any items associated to it, but every item will be associated to at least one product at any time.

Any item can be associated with one or more product, when defining associations, it is possible to constrain each item with a given capacity in a product. Specifying capacities lets the pricing engine know how many items can be sold within a product regardless of how many items are available.

Just like the concept of pricing instances, how products and items are mapped to real objects (if at all) can vary from client to client. A rule of thumb is:

Products determine the prices, while items are the objects being priced.

Examples #

Separate Ticket Types #

In some scenarios tickets are clearly separated, for example early-bird tickets or zone-based seats. A good example would be defining 20 available early-bird tickets, and 80 normal tickets. In this scenario early-bird tickets would have 20 capacity while normal tickets would have 80 capacity of the same product.

Overlapping Ticket Types #

In other scenarios, tickets are part of the same product. In this case the main difference will be the price of the items.

We could say that we have 100 seats for an event, and have VIP/discount/normal tickets to sell. We do not care how the tickets are distributed, we just want to sell 100 of them. This can be expressed by setting the quantity to 100 of each item and then setting a capacity constraint of 100 for the product.

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.