Rate Tables
Rate tables are used to define the price of items (how many tokens are charged per item).
A rate table is defined by the following elements:
| • | Effective Date—The date after which the rate table will be used to calculate token charges. Elastic Access always uses the rate table with the most recent effective date (if more than one version exists). |
| • | Version—Providing different versions of a rate table gives a producer the flexibility to change prices over time, or vary the products and services it contains, while keeping a record of historic prices. Providing a version is mandatory, but it is for the producer’s or end customer’s benefit; Elastic Access does not use the version to determine which rate table to use. |
| • | Series—A rate table may also be defined by a series, which is an optional property. Series are a way to group rate tables. This might be useful, for example, to introduce new prices for a new financial year, or for different divisions within a producer's organization to maintain their own rate tables. Each series will have its own sequence of versions. |
If no series is defined, the rate tables form a single time-based sequence.
| • | Items—An item represents an offering that customers can access in exchange for tokens. An item is defined by a name and an optional version. Each item is assigned a rate that defines the “price” of the item. |
The following is an example of what a rate table might look like:
|
Element |
Child Element |
Type |
Sample Value |
|
effectiveFrom |
n/a |
number |
1693145037000 Note:See Time Fields in Dynamic Monetization for time format information. |
|
version |
n/a |
string |
1 |
|
series |
n/a |
string |
PublicationApps |
|
items |
name |
string |
PhotoPrint |
|
version |
string |
1.0 |
|
|
rate |
number |
3 |
|
|
items |
name |
string |
SignPrint |
|
version |
string |
1.0 |
|
|
rate |
number |
4 |
|
|
items |
name |
string |
CADPrint |
|
version |
string |
2.0 |
|
|
rate |
number |
7 |
Rate table series are a way to associate different sequences of versions together. For a given series (which might be called, for example, “series1”) a sequence of versions of that series could be released over time, giving producers the opportunity to adjust prices within the series or add new technology offerings. If it was decided to “reset” the pricing structure, a new series (for example, “series2”) could be started for subsequent entitlements. For such sequential series, dates might be used for the series name.
Alternatively, several series could be operated in parallel with distinct groups of technology items, separating them for individual marketing purposes, or to support different divisions within a single producer organization.
The following diagram visualizes the relationship between versions and series:
Rate tables diagram showing series and versions
Tip:For detailed information about the rate table structure and its elements, refer to the API documentation.
See also