Table of Contents

SwOTA Point Of Sale

Point of Sale (POS)

The common part of all booking-related requests is the POS section of the message that must contain the valid identifier of the party making the booking. Some of the data ("user" reference – agency, travel agent or client) in this element may be omitted in a message processed within a session (see Session and State Support section), as that information can be identified using session user.

The Point of Sale (POS) identifies also the channel making the booking. In Seaware it translates into Booking Source and (optionally) Distribution Channel. The way to define it is using the CompanyName element text body:

<POS>
   <Source>
      <BookingChannel Type="1">
          <CompanyName>SABRE</CompanyName>
      </BookingChannel>
   </Source>
</POS>

Another important role of POS element is identifying the party (user) that makes the request (can be omitted if request made within a session). There are three user types supported by Versonix OTA:

  • Travel agent
  • Travel agency
  • Client
Note

Security: Available authentication methods depend on your account configuration. During onboarding, you'll receive details about which authentication methods are enabled for your integration (e.g., IATA lookup, username/password, client certificates). If you need additional authentication methods enabled, contact your integration support team.

Identifying Travel Agency POS

Using PseudoCityCode

One of the ways to identify an agency is using the PseudoCityCode:

<POS>
   <Source PseudoCityCode="KK11">
      <BookingChannel Type="1">
          <CompanyName>SABRE</CompanyName>
      </BookingChannel>
   </Source>
</POS>

Using IATA, ABTA, or CLIA Reference

Another way (can be combined with the PseudoCityCode) is to pass agency IATA, ABTA or CLIA reference:

<POS>
   <Source>
      <RequestorID Type="5" ID_Context="IATA" ID="96188116" />
      <BookingChannel Type="1">
          <CompanyName>SABRE</CompanyName>
      </BookingChannel>
   </Source>
</POS>

For CLIA:

<RequestorID Type="5" ID_Context="CLIA" ID="33333"/>

For ABTA:

<RequestorID Type="5" ID_Context="ABTA" ID="12345"/>
Note

Attribute Type="5" indicates that this is an identifier for an agency (not a travel agent or a client).

Using Seaware Agency ID

Seaware Agency ID can also be used to identify agency party:

<POS>
   <Source>
      <RequestorID Type="5" ID_Context="SEAWARE" ID="1234" />
      <BookingChannel Type="1">
          <CompanyName>OPENTRAVEL</CompanyName>
      </BookingChannel>
   </Source>
</POS>

Identifying Travel Agent POS

Using Seaware Agent ID

Seaware agent ID can be used to identify travel agent requestor (using ID_Context="SEAWARE" and Type="29"). That agent's agency will then be used for the booking, so it is not required to specify it explicitly if agent was specified.

<POS>
   <Source>
      <RequestorID Type="29" ID_Context="SEAWARE" ID="8765" />
      <BookingChannel Type="1">
          <CompanyName>OPENTRAVEL</CompanyName>
      </BookingChannel>
   </Source>
</POS>

Using Email

Travel agent can be identified by email (using ID_Context="EMAIL"):

<POS>
   <Source>
      <RequestorID Type="29" ID_Context="EMAIL" ID="test@example.net" />
      <BookingChannel Type="1">
          <CompanyName>OPENTRAVEL</CompanyName>
      </BookingChannel>
   </Source>
</POS>

Using Username and Password

If client application wants to use travel agent's username and password to access Seaware:

<RequestorID Type="29" ID_Context="SEAWARE" Name="john" MessagePassword="secret" />
Note

Here Type="29" indicates the OTA user is "logging in" as a travel agent (that is set up in Seaware with username john and password secret).

Using External Identifiers

External identifiers (per booking source) can be configured (Agent Maintenance > External Systems) and used to identify an agent using the booking source in the ID_Context field and the identifier in the ID field:

<RequestorID Type="29" ID_Context="SABRE" ID="ABC123" />

There is also a way to identify travel agent by external ID when it's set up in Seaware as an additional (dynamic) field (example: SABRE_USER_ID) using the field name (internal) as the ID_Context and the field value in the ID attribute:

<RequestorID Type="29" ID_Context="SABRE_USER_ID" ID="ABC123" />

Identifying Client (Consumer) POS

Using Seaware Client ID

Seaware client ID or club account can be used to identify a client requestor (using ID_Context="SEAWARE" and Type="1"):

<POS>
   <Source>
      <RequestorID Type="1" ID="1001577" ID_Context="SEAWARE" />
      <BookingChannel Type="1">
          <CompanyName>OPENTRAVEL</CompanyName>
      </BookingChannel>
   </Source>
</POS>

Using Username and Password

Another way to specify Client is by using their username and password, or by using their ID and password:

<POS>
   <Source>
      <RequestorID Type="1" ID="0" ID_Context="SEAWARE" MessagePassword="cj0FkF" Name="john"/>
      <BookingChannel Type="1">
          <CompanyName>OPENTRAVEL</CompanyName>
      </BookingChannel>
   </Source>
</POS>
Note

The ID attribute is mandatory, but passing 0 there indicates "no value" to the OTA server. This above is a sample "login"/access using a Client username and password.

Specifying Agent (Agency) and Client

If both Client and Agent (Agency) are identified (e.g. two RequestorID elements, or agent AgentInfo and a Type="1" RequestorID) then SwOTA interprets it in the following way: client is the "user" (that will be in the booking history and the booking Contact) and agent (agency) is assigned to the booking being created (as primary and secondary agent (agency), and their agency is used as booking agency).

Note

Booking Contact can be overridden using ReservationID/TPA_Extensions/ContactInfo/@ContactID.

<POS>
	<Source ISOCurrency="EUR">
		<RequestorID Type="1" ID_Context="SEAWARE" ID="1234" />
	</Source>
	<Source>
		<RequestorID Type="29" ID_Context="SEAWARE" ID="7654" />
		<BookingChannel Type="1">
			<CompanyName>AMADEUS</CompanyName>
		</BookingChannel>
	</Source>
</POS>