Proxy Integration - Reservations

Introduction

The PAYCOMET Proxy service with Booking allows you to tokenize the cards sent in hotel reservations and verify that the card details sent are correct. In order to access this type of integration, you must first have the Booking API integration (https://secure-supply-xml.booking.com - for PCI servers), in which the reservation data is sent since the response will include all the data of the selected reservation and will be added and / or transformed those related to the card.

Types of reservations

The types of reservations that are treated in this integration are those that can be retrieved by means of hotel identifier (hotel_id) and reservation identifier (id). For each reservation a call must be made with these two identifiers.

Reservation statuses

The reservation statuses that are treated by default are:

• new
• modified
• upgrade

If, in addition, your integration needs to deal with the 'canceled' status, please let us know so we can correctly configure the product / terminal.

<reservations>
	<reservation>
		<commissionamount>99.99</commissionamount>
		<currencycode>xxx</currencycode>
		<customer>
		<address></address>
		<cc_cvc>999</cc_cvc>
		<cc_expiration_date>99/9999</cc_expiration_date>
		<cc_name>xxxxxxxxxxxxxxxxxx</cc_name>
		<cc_number>9999999999999999</cc_number>
		<cc_type>xxxxxxxx</cc_type>
		<city>xxxxxxxxxxxxxxx<city>
		<company></company>
		<countrycode>xxxxxxxx</countrycode>
		<dc_issue_number></dc_issue_number>
		<dc_start_date></dc_start_date>
		<email>xxxxxxxxxxxxxxxxxxxxx</email>
		<first_name>xxxxxxxx</first_name>
		<last_name>xxxxxxxx</last_name>
		<remarks>xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx</remarks>
		<telephone>999999999999999</telephone>
		<zip></zip>
		</customer>
		<date>9999-99-99</date>
		<hotel_id>9999999</hotel_id>
		<hotel_name>xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx</hotel_name>
		<id>9999999999</id>
		<room>
			<arrival_date>9999-99-99</arrival_date>
			<commissionamount>99.99</commissionamount>
			<currencycode>EUR</currencycode>
			<departure_date>9999-99-99</departure_date>
			<extra_info>xxxxxx</extra_info>
			<facilities>xxxxxxxxx</facilities>
			<guest_name>xxxxxxxxxxxx</guest_name>
			<id>999999999</id>
			<info>xxxxxxxxxxxxxxxxx</info>
			<max_children>9</max_children>
			<meal_plan>xxxxxxxxxxxxx</meal_plan>
			<name>xxxxxxxxxxxxxx</name>
			<numberofguests>1</numberofguests>
			<price date="9999-99-99"
			genius_rate="no"
			rate_id="9999999">99.99</price>
			<price date="9999-99-99"
			genius_rate="no"
			rate_id="9999999">99.99</price>
			<remarks></remarks>
			<roomreservation_id>9999999999</roomreservation_id>
			<smoking>9</smoking>
			<totalprice>999</totalprice>
		</room>
		<status>new</status>
		<time>99:99:99</time>
		<totalprice>999</totalprice>
	</reservation>
	</reservations>
	<!-- RUID:
   [Umxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxEQ] -->

Tokenization of the card information of a reservation

Upon receiving a reservation, if it contains card data (there are reservations that cannot be processed since they do not contain them), an attempt is made to tokenize them. If all the necessary data is present and it is successful, the node will be added the elements

• iduser
• tokenuser

that represent the tokenized card and that will be necessary for subsequent operations. As of version 1.5, tokenization is allowed even if cvc does not arrive. Please, ask us to enable this option.

Card data transformation

In the returned response, the card will appear masked, 456789 ****** 1234. The expiration date will be returned as it appears in the reservation and the CVC2 code will be removed and will not arrive. Therefore, the previous reservation, once the card information has been tokenized, the node will be as follows:

	<customer>
		<address></address>
		<cc_expiration_date>99/9999</cc_expiration_date>
		<cc_name>xxxxxxxxxxxxxxxxxx</cc_name>
		<cc_number>999999******9999</cc_number>
		<cc_type>xxxxxxxx</cc_type>
		<city>xxxxxxxxxxxxxxx</city>
		<company></company>
		<countrycode>xxxxxxxx</countrycode>
		<dc_issue_number></dc_issue_number>
		<dc_start_date></dc_start_date>
		<email>xxxxxxxxxxxxxxxxxxxxx</email>
		<first_name>xxxxxxxx</first_name>
		<last_name>xxxxxxxx</last_name>
		<remarks>xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx</remarks>
		<telephone>999999999999999</telephone>
		<zip></zip>
		<iduser>999999999</iduser>
		<tokenuser>XXXXXXXXXXXXXXX</tokenuser>
	</customer>

In case of error in preauthorization / cancellation also element ds_error_id

<customer>
…
	<ds_error_id>999999999</ds_error_id>
…
</customer>

In the case of card data, it will also be reported within the customer node whether the card belongs to the B2B category. & lt; b2b & gt; 1/0 & lt; / b2b & gt;

Endpoint and call data

The endpoint to which the request must be made is:

The type of request that it expects is a post with an 'xml' parameter with the following structure:

<root>
	<booking>
		<xml>
			<request>
				<username>vuestro usuario Booking</username>
				<password>vuestra Password Booking</password>
				<hotel_id>id del Hotel</hotel_id>
				<id>id de la Reserva</id>
			</request>
		</xml>
		<url>URL Booking a la que se debe realizar la llamada</url>
	</booking>
	<paytpv>
		<ds_merchant_code>código de comercio en PAYCOMET</ds_merchant_code>
		<ds_merchant_terminal>número de terminal en PAYCOMET</ds_merchant_terminal>
	</paytpv>
</root>

Error response

If an error occurs in the request data or when accessing Booking, the following response will be sent:

<?xml version="1.0" standalone="yes"?>
<reservations>
	<fault code="9999-PAYTPV" string="The type of operation requested doesnt exist" />
</reservations>

Where 9999 will indicate the observed error code.

Sending API-KEYS

In the new Endpoint, the authentication method has been updated from a restriction by IP to sending a specific header with the API-KEY generated for the product / products in question.

The HTTP header must have the following name:

PAYCOMET-API-TOKEN

The value of the header must be the API-KEY generated through the customer control panel: “Configuration” -> Developers -> “API Keys”.

Once in the API Keys management panel, a new 'API KEY' must be created in the upper right button and assigned a name.

In the next panel, the API KEY must be copied since it will only appear once. For security reasons, it will not be shown again. The permissions of the API KEYS can be assigned to one or more products, and even to all of an account using the selectors:

For the product that is going to be used to present the reservations of the OTA (Online Travel Agency) and where the cards will be tokenized, it will be necessary to assign specific permissions of 'Proxy permission' .

Once the API Keys procedures have been completed, the value generated to the API Key must be sent in the header as an authentication method.

Development environment

This development does not have a sandbox where calls can be made with test data. The calls to the script are all real. What must be done to be able to test the integration is to create hotels and test reservations in Booking that allow the complete process to be verified.

Last_change option

For businesses that do not have the option to identify reservations by & lt; id & gt ;, there is the possibility of requesting them using the & lt; last_change & gt; option. All pending reservations will be returned from the date indicated in said element, the corresponding card data transformations will be carried out. They will also be tokenized for later use.

The maximum limit of the time interval to consult is 24 hours.

Call without parameters

The PAYCOMET Proxy service with Booking currently allows receiving requests that do not include the & lt; id & gt; of the reservation, nor the option & lt; last_change & gt ;. In case of not sending any of these two data, PAYCOMET will identify the request as a call without parameters, and the service will return all the reservations that had not been obtained up to that moment. As in the last_change option, the necessary transformations will be carried out on the card data and they will be tokenized to enable their use at another time.