Tracking an External System User’s API transactions (FEA92169)

The SynXis APIs have been enhanced so customers can now provide additional user metadata that will be tracked in SynXis CRS. This metadata will allow visibility into which users from the customer’s application (external system) initiated the API transactions to SynXis CRS.

A new optional parameter (ApplicationUserMetaData) is now supported in the HTTP headers for inbound requests to SynXis CRS, as well as in the header of the token request for use with REST APIs. The ApplicationUserMetaData parameter has a maximum size of 60 characters.

If ApplicationUserMetaData was provided in any reservation transactions via API, the value will be included in Modify Reservation  response message as ResID_Type="3". The following partial XML sample shows how the metadata will be communicated:

<HotelResModifies>
	<HotelResModify>
		...
		<ResGlobalInfo>
			<HotelReservationIDs>
				...
				<HotelReservationID ResID_Type="3"
				                    ResID_Value="ABCD456782"
				                    ResID_Source="Corporation representative"
				                    ForGuest="false"/>
			</HotelReservationIDs>
		</ResGlobalInfo>
		...
	</HotelResModify>
</HotelResModifies>

Channel Reference Number (FEA92863)

Channel Connect now allows a custom booking engine to override stay restrictions if their API user has been granted the access point Override Unavailable Products.

CBE Support Pass-thru Payment Methods (FEA83429)

The Channel Connect API has been enhanced to allow a Custom Booking Engine (CBE) to send the pass-through payment methods.

The following is a partial sample response when a pass-through payment method is successfully added:

 <OTA_HotelResModifyRS>
 	...
	<HotelResModifies>
		<HotelResModify>
			...
			<ResGlobalInfo>
				...
				<Guarantee>
					<GuaranteeDescription Name="PASS-THRU PAYMENTMETHOD">
						<Text>CODE</Text>
					</GuaranteeDescription>
				</Guarantee>
			</ResGlobalInfo>
		</HotelResModify>
	</HotelResModifies>
</OTA_HotelResModifyRS>

Loyalty Accrual Indicator (FEA95383)

Loyalty accrual details have been added to the reservation response.

Sample partial XML response:

<OTA_HotelResModifyRS>
	<HotelResModifies>
		<HotelResModify>
			...
			<RoomStays>
				<RoomStay>
					...
					<RatePlans>
						<RatePlan RatePlanCode="RateCode"
						          RatePlanName="Rate Name"
						          AccrualIndicator="true"
						          AccrualTypeCode="ACCRUAL1"
						          AccrualTypeName="ACCRUAL1 name"
						          PriceViewableInd="true">
							...
						</RatePlan>
					</RatePlans>
				</RoomStay>
			</RoomStays>
			...
		</HotelResModify>
	</HotelResModifies>
</OTA_HotelResModifyRS>

Flexible Points and Cash Redemption Options (FEA92296)

SynXis CRS has been enhanced to allow the configuration of Points and Cash Levels. Hoteliers using Hotel Tiers for Point Redemption can set up the Point and Cash Levels in SynXis CRS to offer multiple PAC rates with different Point and Cash values. In this way the Point and Cash values will take the Point and Cash Levels into account when doing a reservation through the Channel Connect API (OTA_HotelResModifyRQ).

• When calculating the PAC points and cash portions of a product’s price, the system considers the Point and Cash Levels in the Hotel Tier / Hotel Tier Pricing Season.
• The point values returned in the OTA_HotelResModifyRS reflect the Point and Cash Levels calculations.

Same Day Booking with Time Limit (FEA89605)

Configure in Administration > Hotel > Hotel Maintenance > Attributes - Prior Day Booking with Time Limit
SynXis CRS provides the ability to control what time reservations are cut-off from being made for the previous hotel calendar date.

A hotel can use the Prior Day Booking with Time Limit setting in SynXis CRS to define the hour past midnight by which a hotel will allow a reservation to be created or modified for arrival the prior day. The time limit set is local hotel time. In such case, any reservations made in between midnight and the configured time limit will incur charges for the previous day.

Support Custom Call Center Applications (FEA92115)

Enhancements were made to enable Call Center applications, via the Property Direct channel, to make use of the Channel Connect API for their implementations. 

When booking or modifying the reservation, the user can add additional email addresses. They are included in the WrittenConfInst/Email element. Any reservation communications will be sent to the additional email addresses on the reservation, provided that the guest's main email address is included in the request.

These email addresses will be associated to the reservation and not to any guest profile.

<OTA_HotelResModifyRQ PrimaryLangID="en" EchoToken="echo" ResStatus="Commit" xmlns="http://www.opentravel.org/OTA/2003/05">
	…
	<HotelReservations>
		<HotelReservation RoomStayReservation="true">
			…
			<WrittenConfInst>
				<SupplementData Name="CodeTemp"/>
				<Email>Additional1@sabre.com</Email>
				<Email>Additional2@sabre.com</Email>
			</WrittenConfInst>
		</HotelReservation>
	</HotelReservations>
</OTA_HotelResModifyRQ>

The ability to Reinstate Canceled Reservations was also added to the Channel Connect API for the specific use with the Property Direct channel only. To reinstate a previously canceled reservation, the @ResStatus="Reinstate" must be included in the request. In the case of reinstatement, modification requests cannot contain any sections of the message which detail reservation information other than the information needed to identify the reservation to reinstate, like in the following example.

The @HotelCode attribute includes the hotel ID identifying the hotel to search for the existing reservations. When an existing reservation is not found, the reinstatement request is rejected.

• The reinstatement cannot be performed on a reservation that was not previously canceled.
• Canceled reservations with a departure date in the past cannot be reinstated.
• Canceled reservations which used any type of loyalty redemption cannot be reinstated.

Note: The user requesting the reinstatement must have the "Can Reinstate Canceled Reservations" Access Point assigned.

When a canceled reservation is reinstated, the reservation status goes back to confirmed. When a reservation response is returned for a reinstated reservation, it looks identical to a reservation that was never canceled.

<OTA_HotelResModifyRQ EchoToken="12345" ResStatus="Reinstate" xmlns="http://www.opentravel.org/OTA/2003/05">
	<POS>
		<Source>
			<RequestorID ID="2500" ID_Context="Synxis">
				<CompanyName Code="CODE"/>
			</RequestorID>
		</Source>
	</POS>
	<HotelResModifies>
		<HotelResModify>
			<UniqueID Type="14" ID="61028WT000193" ID_Context="CrsConfirmNumber"/>
			<Verification>
				<TPA_Extensions>
					<BasicPropertyInfo HotelCode="12345"/>
				</TPA_Extensions>
			</Verification>
		</HotelResModify>
	</HotelResModifies>
</OTA_HotelResModifyRQ>

Tokenization Support through Channel Connect (FEA53395)

Configure in Administration > Hotel > Payment Processing Settings > Tokenization Settings
Configure in Manage > Reservation > Credit Card Summary

In an effort to enhance our security, Channel Connect and SynXis CRS improved the existing tokenization support. Prior to this release, only clear Credit Card details were accepted as part of the reservation message in Channel Connect. Starting with this release, tokens are accepted as part of reservations through Channel Connect and stored accordingly in SynXis CRS.

The following partial request example includes the tokenized credit card details in the CardNumber element. When a non-empty value is provided in the PaymentCard/@CardNumber attribute, the reservation is not processed. An error is returned which indicates that the credit card details must be included in either PaymentCard/@CardNumber or PaymentCard/CardNumber.

<ResGlobalInfo>
	<Guarantee>
		<GuaranteesAccepted>
			<GuaranteeAccepted>
				<PaymentCard CardCode="VI" ExpireDate="0919" SeriesCode="123">
					<CardHolderName>Card Holdername</CardHolderName>
					<CardNumber Token="AEGHV234AUD54367"/>
				</PaymentCard>
			</GuaranteeAccepted>
		</GuaranteesAccepted>
	</Guarantee>
	…
</ResGlobalInfo>

The following is a partial response example:

<ResGlobalInfo>
	<Guarantee>
		<GuaranteesAccepted>
			<GuaranteeAccepted>
				<PaymentCard CardType="1" CardCode="VI" CardNumber="XXXXXXXXXXXX4367" ExpireDate="0919">
					<CardHolderName>Card Holdername</CardHolderName>
					<CardNumber Token="AEGHV234AUD54367"/>
				</PaymentCard>
			</GuaranteeAccepted>
		</GuaranteesAccepted>
	</Guarantee>
	…
</ResGlobalInfo>