-
Notifications
You must be signed in to change notification settings - Fork 41
Fare construction
The fare can be constructed out of multiple items. The fare communicated from TO to MSP is the fare the TO will be charging the MSP. How the MSP will charge it to the end user, is up to the MSP.
The fare consists of a serie of 'fare-parts'. Each part has it's own type.
The first and simplest part is the fixed price (e.g. 12.50 EUR).
{ "amount": 12.50, "currency-code": "EUR", "tax-rate": 21.0, "type": "FIXED" }
Another possibility is a price per time unit (e.g. 1.50 EUR per hour or 0.25 NNK per quarter of an hour)
{ "amount": 1.50, "currency-code": "EUR", "tax-rate": 21.0, "type": "FLEX", "unit-type": "HOUR", "units": 1 }
{ "amount": 0.25, "currency-code": "NNK", "tax-rate": 6.0, "type": "FLEX", "unit-type": "HOUR", "units": 0.25 }
And, of course, there are mixed possibilities (e.g. 1.50 USD start up costs and 0.50 USD per each half hour)
[{ "amount": 1.50, "currency-code": "USD", "tax-rate": 2.0, "type": "FIXED" },
{ "amount": 0.50, "currency-code": "USD", "tax-rate": 6.0, "type": "FLEX", "unit-type": "HOUR", "units": 0.5 }]
All these possibilities are possible in the fare construction. There is no other way of getting the total amount of fare than by processing all fare parts to avoid inconsistency.
The scale construct uses has 2 properties scaleFrom
and scaleTo
. The scaleFrom
is inclusive, the scaleTo
is inclusive as well.
"fare": {
"class": "FARE",
"parts": [
{
"amount": 0.01,
"currencyCode": "EUR",
"vatRate": 21,
"vatCountryCode": "NL",
"type": "FLEX",
"unitType": "MINUTE",
"units": 1,
"scaleFrom": 0,
"scaleTo": 59,
"scaleType": "MINUTE",
"class": "FARE"
}
]
}
This means we'll have to pay EUR 0.01 (incl. VAT) per minute, for the first 60 minutes of the ride. Another part should describe the other minutes, so it should start with 60.
Introduction
- Roadmap
- Semantic versioning
- Use cases
- Changes per version
- Contribution
- Participants
Workflow
- Operator information
- Planning phase
- Booking phase
- Trip execution phase - start
- Trip execution phase - on route
- Trip execution phase - end
- Support
- Payment
Points of attention
- Modalities
- Specifying locations
- GDPR
Eco system
- Relations
Introduction
Scope of the TOMP-API
Versioning and releases
Process Flows
- Authentication
- Operator Information
- Privacy and Registration
- Planning Module
- Booking Module
- Trip Execution Module
- Payment Module
- Support Module
Meta-Information
Reference implementations
To-dos and risks
Technical Specifications
A1 List of terms and definitions
A2 Passenger characteristics dictionary
A3 APIs available on the transportation ecosystem
A4 Overview of the User stories
A5 Authors, Architects, collaborators and stakeholders involved
A6 Adoption and Implementation of the TOMP-API