Replies: 3 comments
-
|
I agree! This could maybe also be extended to include terms and agreement etc for the purchaser? |
Beta Was this translation helpful? Give feedback.
-
|
No necessarily need for a dedicated API if this kind of requirement are included in the description of each offer element, at offer step. |
Beta Was this translation helpful? Give feedback.
-
|
As well TOMP-API as OMSA can deliver 'Links' (next steps). In the links, you can specify the required fields. OSDM has another mechanism to specify which fields are required. And, indeed, they should only be required when booking/purchasing. These fields should never be exposed when retrieving a Booking/Package due to the GDPR. Parts can be shown (data minimalisation) on e.g. tickets for validation purposes. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
In a multi-leg journey, there may be different requirements for traveler information on each leg. For instance, some tickets will need the traveler name, some will require the birth date for the children in the travel party, and on a particular leg that crosses the Schengen border, you may need to provide your passport number.
After putting offers for several legs and several travelers in a shopping basket, the client should be able to ask the server for a list of required traveler details per traveller and leg. There should be a standardized list of fields that includes the semantic meaning, the data type and the format of the data, that should be used in the response.
For instance
[+][Country Code][Subscriber Number](E.164 standard)The response should list the required fields per traveler and leg. The client would use this list to display a form for collecting traveler information and send it to the server. The server would forward the relevant information to the operator for that particular leg, and not to the other operators in the journey, as per GDPR.
Beta Was this translation helpful? Give feedback.
All reactions