/
Digital TT Card / Y2M-Interface description

Digital TT Card / Y2M-Interface description

Innledning

Dette dokumentets formål er å beskrive de tekniske aspektene ved «digitalt TT-kort»

Dokumentet vil først presentere overordnet flyt og logikk før detaljer rundt meldingsstruktur i Ruters API presenteres.

Flyt

Initiering av tur

  • Ruter vil tilby en web portal for oppslag på kunder før turer. Denne siden kan brukes ved forhåndsbestilling fra kunde og vil ikke brukes ved praiing av Taxi.

  • Ved praiing vil kunden oppgi at turen er en TT-tur når de setter seg inn i Taxien. Deretter må kunden verifiseres

 Verifisering av bruker

  • For forhåndsbestilte turer er det ikke behov for verifisering av bruker og turen kan starte direkte

Verifisering av kunde med telefonnummer:

  • Kunden oppgir sitt telefonnummer og sjåføren registrerer det på sin terminal.

  • Systemet må kalle Ruters API med telefonnummeret som kundens identifikator

  • Ruter vil sende en SMS til kunden som kunden må oppgi til sjåføren

  • Sjåføren taster inn koden på sin terminal som igjen kaller Ruters API

  • APIet vil returnere status og ved positiv respons kan turen starte.

  • Respons for godkjent tur vil også inneholde kundeinformasjon

Verifisering av kunde uten telefonnummer:

  • I noen tilfeller vil ikke kunden ha telefonnummer. De kan da oppgi kundenummeret sitt (som vil stå på TT informasjonskortet)

  • Sjåføren taster inn kundenummer og systemet gjør et kall mot Ruters API

  • APIet vil returnere gyldig kundenummer med kundedetaljer (som kan brukes for å identifisere bruker mot annen identifikasjon)

  • Turen kan starte

Oppstart av tur

  • Når turen er bekreftet og kan starte skal Ruters API kalles for å bekrefte start av turen

  • Dette gjelder alle turer uavhengig av verifisering

Avslutte tur

  • Når turen er avsluttet skal en oppsummeringsmelding sendes via Ruters API

Betaling utført

  • Etter gjennomført betaling skal en oppsummeringsmelding for betaling sendes via Ruters API

API

Verifisering av bruker

Headers:

{ “Authorization”: “Bearer …” }

POST:  trip/create/challenge

Description: Endpoint that generates an SMS that is sent to the customer with a code that will be used to verify the customer.

Body:
{             “phone_number”: “string” //ex. “phone_number”: “+4745454545”  }
Responses:

statusCode: 200

{ status: “ok” }

statusCode: 404

POST:  trip/create/verify

Description: Endpoint for verifying the customer.

Body
Responses:

statusCode: 200

statusCode: 404

statusCode: 403

POST:/trip/create/code

Description: Endpoint used when the customer doesn’t have a phone, or doesn’t want to use it.

Requires the customer to have the physical TT-card, or know their id

Body
Responses:

statusCode: 200

statusCode: 404

statusCode: 403

Oppstart av tur

POST: /trip/start/:trip_id

Description: Endpoint to start the trip. The driver must verify that the information about the customer is likely correct.

Parameter: :trip_id = unique id for trip, retrieved after the customer has been verified

Body:
Response:

statusCode: 200

Avslutte tur

POST:/trip/end/:trip_id

Description: Called once the taximeter is stopped.

Parameter: :trip_id = unique id for trip, retrieved after the customer has been verified

Body:
Response:

statusCode: 200

Betaling utført

POST:/trip/end/:trip_id/payment

Description: Endpoint called after the customer has paid.

Parameter: :trip_id = unique id for trip, retrieved after the customer has been verified

Body:
Response:

statusCode: 200

 

Related content

Avtale om Digitale Tjenester v. 2.6
Avtale om Digitale Tjenester v. 2.6
More like this
Filformat URF, Utvidet Rebusformat
Filformat URF, Utvidet Rebusformat
Read with this
Avtale om Digitale Tjenester v. 2.4
Avtale om Digitale Tjenester v. 2.4
More like this
API v. 2.3
Read with this
Avtale om Digitale Tjenester v. 2.5
Avtale om Digitale Tjenester v. 2.5
More like this
Avtale om Digitale Tjenester
Avtale om Digitale Tjenester
Read with this