Third-party Payment Specification for MaaS Brecht Van de Vyvere1[0000−0002−7671−6203] , Tim Asperges2 , Pieter Colpaert1[0000−0001−6917−2167] , and Ruben Verborgh1[0000−0002−8596−222X] 1 IDLab, Department of Electronics and Information Systems, Ghent University – imec {brecht.vandevyvere,pieter.colpaert,ruben.verborgh}@ugent.be https://idlab.technology/ 2 City of Leuven, Belgium tim.asperges@leuven.be Abstract. Mobility as a service (MaaS) allows intelligent transporta- tion across multiple mobility providers, such as calculating the least ex- pensive route. However, the current standards do not tackle third-party payments (TPPs) where a third party compensates a part of a travellers’ trip cost when certain criteria are met. For example, travellers receive 10% discount from a local government when renting a shared bike in the cities’ centre during peak hours. To automatize TPP agreements for MaaS, we propose and demonstrate with an example (i) a specification to set up a TPP system specifying, among others, how multimodal cri- teria and trips can be semantically described, and (ii) an open source validator tool returning the compensation for a trip. In future work, we are investigating how personal data can be integrated using Solid data pods. Keywords: Third-party payments · Mobility as a Service · Local deci- sions. 1 Introduction Standardized data models (General Transit Feed Specification (GTFS) [9], Mobility Data Specification (MDS) [8]) or Web Application Programming In- terfaces (APIs) (General Bikeshare Feed Specification (GBFS) [1], Transport Operator, MaaS Provider (TOMP) API [10]) allow MaaS providers to calculate the financial cost of a trip for transportation. However, this does not exist for third-party payment schemes. The term ’third-party payment’ (TPP) in the con- text of MaaS refers to the compensation a traveller receives from a third party, such as a local government, when a trip is performed compliant with the third parties’ criteria, such as student discounts. Next to the regular payment from Copyright © 2021 for this paper by its authors. Use permitted under Creative Com- mons License Attribution 4.0 International (CC BY 4.0). 2 B. Van de Vyvere et al. the traveller to the used mobility service, a second payment is performed from the third party to the traveller or service, depending on the implementation of the TPP system (see Section 2). According to the overview provided in Table 1, some TPP systems are already set up between local governments and mobility providers to increase the accessibility of shared mobility to certain groups, such as tourists or children, or during an event. These criteria are based on loca- tion, time, transport modality and traveller’s profile information and are defined in local decisions in the form of subsidy measurements. A TPP system can be achieved in a pre- or postpaid fashion. From the view point of a traveller, with prepaid, a smaller part of the trip must be paid by the traveller: a split bill occurs where the second part is arranged between the third party and mobility provider. With postpaid, a traveller pays the total trip cost to the mobility provider and receives its compensation afterwards from the third party. Based on the advice of some cities (Leuven, Antwerp), we will focus in this article on prepaid so groups with a low income or certain social background can be compensated on the mo- ment of ticketing. Prepaid can be implemented with vouchers or mobility budget containing, for example, free rides or credit. Another approach is an agreement describing the subsidy measurement criteria and how a mobility provider can send an invoice afterwards to the third party. Currently, these TPPs are made ad hoc lowering the discoverability and reusability for route planning advice in MaaS. Therefore, we propose a specification for a prepaid TPP system defining the semantic description of subsidy measurements and trips, and an open-source validator to verify whether a trip is compliant with a subsidy measurement. Table 1. State of play of third-party payment schemes in Flanders. City Description Provider Criteria Deinze Free rides with shared bikes Blue Bike Location of the trip must be in Deinze Leuven Free rides with bus De Lijn Citizens younger than 12 years of district Leuven Leuven Discount on public transport NMBS and During certain events De Lijn Schoten Vouchers for 20 minutes free Mobit During certain events rides with shared bike 2 Third-party payment specification for MaaS 2.1 Preliminaries Open Standards for Linking Organizations (OSLO) [3], a program of the Flan- ders Information Agency enables organizations in Flanders to cooperate in tra- jectories, to develop unambiguous standards for information exchange. The “OSLO mobility: trips and offer” standard [12] was triggered by the new decree Basic Third-party Payment Specification for MaaS 3 Accessibility in Flanders [11], which states that important social locations must be optimally accessible to travellers. To realize this, a traveller must have a clear view on the existing mobility offer and on how to interconnect the vari- ous transport options in a multimodal mobility context. The standard consists of a vocabulary for describing trips, transport networks and service offerings, and of a “trips and offer” application profile (AP). The AP specifies which data needs to be exchanged concerning i) trips done by users and ii) the mobility services at their disposal. This AP allows mobility providers to describe trips in a machine-readable way. The Local Council Decisions as Linked Open Data (LBLOD) programme is a Flemish initiative to semantically annotate decisions of local governments [2]. Local administrations currently have to upload decisions from their organization into Flemish base registries, such as the database for mandates, or road signs. By embedding RDFa in their documents, the Flemish government and third parties can harvest the information themselves in an automatic way, similarly to search engines that harvest Schema.org annotations from websites. LBLOD has already initiated several OSLO trajectories for domain-specific decisions, such as the installment or removal of mandataries [4], traffic [6] and subsidy regulations [5]. The “subsidies” AP reuses terms from the European ISA standard Core Criterion and Core Evidence Vocabulary (CCCEV) [7] to describe criteria, requirements and how to group them. This AP allows local governments to define TPP subsidy measurements, its criteria and monetary compensation in a machine-readable way. 2.2 System overview The TPP specification describes the steps local governments and mobility opera- tors can perform to compensate a travellers’ trip [13]. According to the overview provided in Fig. 1, the system starts with the local government (agency), that defines which trips can be compensated (i). When a MaaS provider can imple- ment the subsidy and conforms with the cities’ quality framework (QF), a TPP agreement can be arranged (ii), which is annotated according to the LBLOD AP for subsidies [5]. The trip of a user is described with the OSLO AP “trips and offer” [12] (iii) and can be validated with the semantically annotated agree- ment (iv). When a trip meets the criteria, the validator returns how much can be compensated (v). For reimbursement, the mobility provider sends an invoice with the number of trip compensations (vi). In future work, the agency should be able to verify with the validator whether the compensated trips in the report are legitimate. To do so, the report will also need to embed the machine-readable description of the compensated trips as proof. 2.3 Example Inspired by projects like MDS [8] and LBLOD [5], we specify which standards to use to describe subsidy measurements and trips, and how trips can be validated in an automated fashion. We provide a JavaScript Object Notation Linked Data 4 B. Van de Vyvere et al. Fig. 1. Overview of setting up a TPP scheme between an agency (top row) and MaaS provider (bottom row). (JSON-LD) template with corresponding table for each type of object. This way, developers do not need to understand semantic technologies to start mapping their data. A JSON-LD context is added to make the template semantically interoperable. In Listing 1.1, we give an example of a requirement for shared bikes in Leuven. Next to RouteSegmentRequirements, an agency also needs to describe the SubsidyMeasurement, which combines multiple requirements, and Payment indicating how much will be compensated. More details can be found on the Github repository of the specification[13]. Similarly, providers need to map every trip to ”trips and offer”[12]. A trip ex- ecutes a certain route composing multiple route segments. These segments spec- ify the departure and arrival time, GPS telemetry, price and transport modality. For example, Listing 1.2 demonstrates a shared bike system during rush hours costing 8.2 Euro. With the standardized description of a trip and subsidy measurement as input, an open source validator is being developed returning whether a trip is conform with the subsidy measurement and how much compensation can be given [13]. MaaS providers can incorporate this tool into their route planning engine. Also, agencies could use this tool as validation step before payment. Listing 1.1. Travellers are eligible for a subsidy measurement when they use a shared bicycle within the centre of Leuven and on a monday during rush hours. { " @type " : " R o u t e S e g m e n t R e q u i r e m e n t " , " description " : " Only shared bikes , on monday between 4 pm and 6 pm and used in the city centre of Leuven ." , " meansOfTransport " : " http : // www . wikidata . org / entity / Q 1 3 5 8 9 1 9 " , // Bike " location " : { " @type " : " Place " , " geometry " : { " wkt " : " POLYGON (( 4 . 6 7 6 0 5 5 9 0 8 2 0 3 1 2 4 5 0 . 8 8 9 9 3 2 0 5 7 6 6 3 1 2 ...) ) " } Third-party Payment Specification for MaaS 5 }, " time " : [ { " @type " : " O p e n i n g H o u r s S p e c i f i c a t i o n " , " dayOfWeek " : " http : // schema . org / Monday " , " startTime " : " 1 5 : 0 0 : 0 0 " " endTime " : " 1 8 : 0 0 : 0 0 " }] } Listing 1.2. This route segment is performed during rush hours in the centre of Leuven with a shared bike system. { " @type " : " RouteSegment " , " departureTime " : " 2 0 2 0 -0 6 -0 9 T 1 6 : 0 1 : 0 0 " , " arrivalTime " : " 2 0 2 0 -0 6 -0 9 T 1 7 : 0 5 : 0 0 " , " telemetry " : [ "..." ] , " price " : { " @type " : " MonetaryAmount " , " value " : " 8 . 2 " , " currency " : " EUR " }, " meansOfTransport " : " http : // www . wikidata . org / entity / Q 1 3 5 8 9 1 9 " // Shared bike } 3 Conclusion The specification and validator proposed in this demo set the first steps towards third-party payments for MaaS. In future work, we want to make TPPs on the one hand more inclusive and on the other hand use the validator in a generic, cross-domain incentives (subsidy measurements) platform. Both aspects require the use or creation of personal data: the validator will need to be extended to handle profile information, and incentives should be assignable to a person. As cities nor MaaS operators should be responsible for managing personal data, we are looking into using Solid data pods, an innovative data storage solution for private data. With this last element added, we hope to have an interesting discussion during the workshop about the future ecosystem of TPPs for MaaS. References 1. Association, N.A.B.S.: General bikeshare feed specification, https://github.com/NABSA/gbfs 6 B. Van de Vyvere et al. 2. Buyle, R., Colpaert, P., Van Compernolle, M., Mechant, P., Volders, V., Verborgh, R., Mannens, E.: Local council decisions as linked data: a proof of concept. In: Kawamura, T., Paulheim, H. (eds.) Proceedings of the 15th International Semantic Web Conference: Posters and Demos. CEUR Workshop Proceedings, vol. 1690 (Oct 2016), http://pieter.pm/iswc2016-demo-lbld/ 3. Buyle, R., De Vocht, L., Van Compernolle, M., De Paepe, D., Verborgh, R., Van- lishout, Z., De Vidts, B., Mechant, P., Mannens, E.: Oslo: Open standards for linked organizations. In: Proceedings of the International Conference on Electronic Governance and Open Society: Challenges in Eurasia. pp. 126–134 (Nov 2016). https://doi.org/10.1145/3014087.3014096, https://dl.acm.org/authorize?N20629 4. for Domestic Governance, F.A.: Lblod mandate registery, https://data.vlaanderen.be/doc/applicatieprofiel/mandatendatabank/ 5. for Domestic Governance, F.A.: Lblod subsidies, https://data.vlaanderen.be/doc/applicatieprofiel/besluit-subsidie/ 6. for Domestic Governance, F.A.: Lblod traffic measurement, https://data.vlaanderen.be/doc/applicatieprofiel/besluit-mobiliteit/ 7. programme European Union, I.: Core criterion and core evidence, https://joinup.ec.europa.eu/release/core-criterion-and-core-evidence-vocabulary- v100 8. Foundation, O.M.: Mobility data specification (mds), https://github.com/openmobilityfoundation/mobility-data-specification 9. Google: Gtfs overview, https://developers.google.com/transit/gtfs 10. working group, T.: Transport operator mobility provider (tomp) api development for mobility as a service, https://github.com/TOMP-WG/TOMP-API 11. of Mobility, D., Works, P.: Decree basic accessibility, https://www.vlaanderen.be/basisbereikbaarheid/het-decreet-basisbereikbaarheid 12. OSLO: Oslo mobility: trips and offer, https://data.vlaanderen.be/doc/applicatieprofiel/mobiliteit- trips-en-aanbod/ 13. Van de Vyvere, B., Venselaar, M.: Third-party payment specification, https://github.com/brechtvdv/third-party-payment-maas-specification