Proxy Integration - Wubook
Introduction
The PAYCOMET Proxy service with WuBook allows tokenize the cards registered in the hotel reservations and verify that the formats of the card data received in them are correct. To be able to access this type of integration, you must first have the WuBook API integration (http://tdocs.wubook.net/wired.html) , in which the identifying data of the card included in the selected reservation is sent and the modified and tokenized card information is returned.
Types of requests
The types of requests that are handled in this integration are those that can be retrieved by calling the fetch_cc (token, building_id, booking_code, building_password) method.
As is mandatory, also those for obtaining / releasing the previous / subsequent token, acquire_token and release_token methods.
Example of information contained in a fetch_cc request
<?xml version="1.0"?> <methodResponse> <params> <param> <value> <struct> <member> <name>cc_type</name> <value> <int>1</int> </value> </member> <member> <name>cc_number</name> <value> <string>4111111111111111</string> </value> </member> <member> <name>cc_cvv</name> <value> <string>123</string> </value> </member> <member> <name>cc_code</name> <value> <nil/> </value> </member> <member> <name>cc_owner</name> <value> <string>John Doe </string> </value> </member> <member> <name>cc_expiring</name> <value> <string>01/2020</string> </value> </member> </struct> </value> </param> </params> </methodResponse>
Tokenization of the card information of a reservation
Upon receiving a fetch_cc request response, if it contains card data (cc_number, cc_expiring, cc_cvv must be present), an attempt is made to tokenize them. If all the necessary data are present and it is successful, the elements will be added
- iduser
- tokenuser
that represent the tokenized card and that will be necessary for subsequent operations. As of version 1.1, tokenize 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, 411111 ****** 1111. The expiration date will be returned as it appears in the response to the fetch_cc request and the CVC2 code will be removed and will not arrive. Therefore, the previous reservation, once the card information has been tokenized, will be as follows:
<?xml version="1.0"?> <methodResponse> <params> <param> <value> <struct> <member> <name>cc_type</name> <value> int>1</int> </value> </member> <member> <name>cc_number</name> <value> <string>411111******1111</string> </value> </member> <member> <name>cc_cvv</name> <value> <nil/> </value> </member> <member> <name>cc_code</name> <value> <nil/> </value> </member> <member> <name>cc_owner</name> <value> <string>John Doe</string> </value> </member> <member> <name>cc_expiring</name> <value> <string>01/2020</string> </value> </member> <member> <name>id_user</name> <value> <int>99999999</int> </value> </member> <member> <name>token_user</name> <value> <string>WWXXwwXWWXxWWXxWWxxWW</string> </value> </member> </struct> </value> </param> </params> </methodResponse>
In case of an error in the tokenization, the iduser / tokenuser elements will not appear and a ds_error_id element will be added
<struct> ... <member> <name>ds_error_id</name> <value> <int>1195</int> </value> </member> ... </struct>
Acquire_token and release_token requests
These requests are necessary based on the WuBook integration and the proxy allows them both. The three allowed calls are specified in the next point.
Endpoint and call data
The script to which the request must be made is:
- https://eclipse.paycomet.com/api/v1/wubookThe type of request it expects is a post with an 'xml' parameter with the following structure:
<root> <booking> <xml> <request> <method>nombre_metodo</method> <params> 1.- acquire_token <user>usuario</user> <password>password</password> <provider_key>provider_key</provider_key> 2.- fetch_cc <token>token</token> <building_id>building_id</building_id> <booking_code>booking_code</booking_code> <building_password>building_password</building_password> 3.- release_token <token>token</token> </params> </request> </xml> <url>URL Wubook a la que se debe realizar la llamada</url> </booking> <paytpv> <ds_merchant_code>código de comercio en PAYTPV</ds_merchant_code> <ds_merchant_terminal>número de terminal en PAYTPV</ds_merchant_terminal> </paytpv> </root>
If you want to make the acquire_token call, it must be indicated in the & lt; method & gt; element. and send the necessary parameters / elements (user, password, provider_key).
Similar in the other methods. For fetch_cc indicate it in the element & lt; method? & Gt; and send token, building_id, booking_code and building_password.
To release the token, indicate release_token in the method element and send its value in the token element.
Error response
If an error occurs in the request data or when accessing WuBook, an error message will be sent the same as the one currently returned by WuBook, with the following consideration: if the error occurs in the call to PAYCOMET (credentials, format) or in the call from PAYCOMET to WuBook (timeout, no response, etc.) the error identifier will be that of PAYCOMET and the description of the error will be that of PAYCOMET indicating that there has been no connection establishment with WuBook. Once that point is passed, if an error occurs, exactly what is returned by WuBook will be returned:
PAYCOMET error prior to the call to Wubook:
<?xml version="1.0"?> <methodResponse> <params> <param> <value> <array> <data> <value> <int>1121</int> </value> <value> <string>Client not found</string> </value> </data> </array> </value> </param> </params> </methodResponse>
Error returned by WuBook:
<?xml version="1.0"?> <methodResponse> <params> <param> <value> <array> <data> <value> <int>-2</int> </value> <value> <string>Invalid Token</string> </value> </data> </array> </value> </param> </params> </methodResponse>
The PAYCOMET error codes can be found at this url: https://docs.paycomet.com/en/recursos/codigos-de-error
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 test hotels and reservations in WuBook that allow to verify the complete process.