BankStore XML Integration

Introduction

The aim of this document is to serve as a reference during the integration process of a business with the PAYCOMET payment gateway, using the system BankStore that stores bank details of the customers of the business.

It also includes a reference Appendix and a document, including the error codes returned by the system to simplify the debugging process, is available on the website of PAYCOMET.

Las integraciones XML y REST through the BankStore service allows access to payment transactions without direct user intervention, extending the operation of individual payment to the management of the bank details of the customer of the business. The requests originate at the server of the business and are processed by the payment gateway.

Both technologies for carrying out operations allows safe passage through firewalls and through the network. In addition, you can use Full screen, Iframe and JET-IFRAME to capture card data.

The BankStore service is differentiated by its communication between the business and the gateway combining information on customer data. The business stores personal data of its customer and PAYCOMET the bank details. Once the business registers the user, PAYCOMET returns an identifier formed by a unique customer number (IDUSER) and a token (TOKENUSER).

In this way the business has a common identifier with PAYCOMET to perform operations on your customer account such as:

• User Registration (add_user)
• User Info (info_user)
• User Removal (remove_user)
• User Purchase (execute_purchase)
• User Purchase with DCC (execute_purchase_dcc)
• Purchase confirmation with DCC (confirm_purchase_dcc)

The subscription operation has been added in the same service. This operation is completely parallel to that of storage of bank details of the customer. The management of subscriptions will be carried out with the following functions:

• Subscription registration (create_subscription)
• Editing a subscription (edit_subscription)
• Subscription removal (remove_subscription)

Also, operations related to preauthorizations are also present through the functions:

• Preauthorization registration (create_preauthorization)
• Preauthorization confirmation (preauthorization_confirm)
• Preauthorization cancellation (preauthorization_cancel)

In this way, two concepts are divided into the same service and it is necessary to clarify their purpose and differences:

Operation Notification: Webhook

The purchase process is carried out by the payment gateway and the resolution of the operation is returned directly in the response message. However, it is possible to configure through the PAYCOMET customer panel additional notification methods to keep users informed of the operation or launch additional mechanisms.

These notifications are identical to those submitted by other type of payment gateway products such as WEB gateway or telesales. Thus, it is possible for the customer to maintain a unified control of sales made by the business.

For proper notification of the payment process, it is possible to configure the notification system to provide information on the status of the operation performed by the gateway, either via e-mail, request to URL in the background (independent of the response process to the service) or both, and in general by SMS.

Email

The information contained in a standard notification e-mail is as follows:

		
			A sale has been performed according to the following parameters:

			Account identifier: 0gs265nc

			Transaction type: Authorization (1)

			Card issuing country: ES

			Date and time of the transaction (yyyymmddhhmmss): 20101027110536

			Order: 2010102711053676

			Response: OK

			Error ID: 0

			Error description:

			Authentication code: 802335/120098123810102711053606007000

			Currency: EUR

			Amount (Euros): 10.00

			Amount (Origin): 1000

			Language: es

			Product ID: 25

			Signature:

			Extended Signature: 94f487ad8b57141d91fbc8fcda9e346cf17254bc

			Secure Payment: 0

			Scoring: 0

			Card Brand: VISA

			BIC Code: BSABESBBXXX

			Serial Number: 00000200275

			PAYCOMET ID: 122548686

		
	

Request to URL

The notification parameters are passed to the target URL using the POST method according to the following table:

The Extended Signature for verifying notifications (NotificationHash) will be calculated in the following manner:

POS configuration

In order to use the PAYCOMET payment gateway in your business, you must have the necessary configuration parameters. These can be obtained through the PAYCOMET customer management platform at Customer Area

Once inside the platform, the configuration of the contracted product can be reviewed through the menu Terminals->"Terminal name"->Terminal details.

After clicking the chosen terminal, a screen will appear with the basic information of the product under the section "Integration credentials". Specifically, the information required during the integration process is:

• Password
• Terminal number
• Customer code
• URL of the service (https://api.paycomet.com/gateway/xml-bankstore)
• URL of the web service description file (WSDL) by way of reference (https://api.paycomet.com/gateway/xml-bankstore?wsdl)

Integration for data capture

To facilitate compliance with the PCI-DSS standard, the business has the solution for data capture of their customer by using customizable IFRAME.

This solution enables the generation of a form of data captura with the look&feel predefined in the product control panel. This solution must be activated by PAYCOMET, so if it does not appear in the control panel, you must request it by opening an administrative ticket (Support → Open ticket → Administrative/Operational).

In this section you will be able to see a preview of the styles applied below. Styles allow reference to external sites but must respond with a digital certificate correctly signed by a trusted entity; otherwise the customer browser will display an error that will generate mistrust in your customer:

The template can be customized from the section: (Terminals->"Terminal name"->Payment form). Here are the fields that can be modified using CSS styles and a preview of said changes.

If the available properties do not meet the needs of the application, you may request a development of specific "Template" by opening an administrative ticket (Support → Open ticket → Administrative/Operational).

We will inform you of the steps to be followed and the rules of said development.

The functionalities available in Bankstore IFRAME are

• Function: (add_user)
• Function: (execute_purchase)
• Function: (create_subscription)

Said functionalities are those that involve the collection of the bank details of the customer. Subsequently, once the IDUSER and TOKENUSER data have been collected, XML and REST interfaces may be used to execute purchases, modify subscriptions, information of user card data, cancel subscriptions, etc...

Operation of the data capture (example)

The purpose of using an integration to capture customer card data is to facilitate compliance with the PCI-DSS standard of the Web application. In this manner, the collection of bank data is carried out in the PAYCOMET secure environment for processing them later in a Server2Server conversation without risk of the data being susceptible to theft.

In a fictional environment we would find the following scenario:

A business with high recurrence wants to store the bank details of the customer to facilitate future purchases. The techniques for collecting their bank details are two:

• From their customer account. In their control panel they can modify their billing and shipping information and even their associated credit/debit card. Thus, at the end of the shopping cart, they will make the order payment with just one click.
• In the first purchase. The customer enters all their bank details in the final process of the cart and these will be stored for future purchases. In this way, storage is done in a "transparent" way when completing the order.

In the first case, the customer is authenticated on the e-commerce platform because it is a previously registered user. They login to their Control Panel and chose to add a credit/debit card to their account to make the payments. The business shows in an integrated way in their control panel an form to capture data and PAYCOMET notifies the business of the result. The business stores the IDUSER and TOKENUSER data in the customer's account (they may have several, in order to have multiple cards), to subsequently make payments.

The customer enters the data into on PAYCOMET's form (aesthetically integrated with the web of the business) and PAYCOMET notifies the IDUSER and TOKENUSER data in the case of success, with a delay.

The business stores the data associated with the account of its customer to execute a payment through SOAP XML integration.

In the second case (storage on the first purchase), the customer places an order normally and when selecting the method of payment by credit/debit card, the bank details are requested to proceed to

The bank details are introduced in an capture form generated by PAYCOMET returning both the storage data of the user (IDUSER and TOKENUSER) and the result of the transaction.

This will happen only if the business does not have the two IDUSER and TOKENUSER data. Otherwise the communication would not be done by a capture form.

In the situation where the business has the IDUSER and TOKENUSER data, either by obtaining them through add_user, the customer has entered their data from their control panel of the business, or through execute_purchase, the customer has already made a purchase previously, the method for making a purchase is different. The method to be used shall be by a Server2Server (XML or REST) connection where the business will use the execute_purchase service directly with PAYCOMET.

It is recommended to use some kind of authentication (PIN or similar) to execute the execute_purchase service to prevent unsolicited purchases.

Said unsolicited purchases are usually subject of dispute of the operation and may incur additional charges from the bank and, if it is a repeated offense, the account could be canceled.

Methods of payment according to the integration

It is important to understand the two integrations in order to build the operation of the business.

Cobros mediante Operativa DCC

PAYCOMET allows transactions to be carried out through BankStore operations, in DCC modality (Dynamic Currency Conversion).

Dynamic Currency Conversion (DCC) converts international purchases with Visa® and MasterCard® credit cards into the local currency of the cardholder. Part of the conversion charge will be refunded to the business. PAYCOMET administrates the full conversion process; from the direct exchange rates of the treasury and processing of transactions, to conciliation of deferred payments, liquidation, financing and support.

With DCC, international clients will know the exact total of the purchase in their local currency. Conversion rates are generally much more competitive than those of exchange companies.

This operation must be activated before use. Contact us to register for the desired product.

DCC integration differs from conventional integration due to the use of a specific service for carrying out the client payment. The services dedicated to DCC are:

• User Purchase with DCC
• Purchase confirmation with DCC

The user registration procedure: add_user, continues to be necessary in the case of purchases without 3D Secure. The main difference is the incorporation of an additional step for receiving the available exchange of the native currency of the card at the time of the transaction:

BANKSTORE XML Integration

Since the entire payment process is performed in the background (server to server) the changes to be performed in the business are totally unrelated to the user experience.

The technology used for the operation with the PAYCOMET payment gateway is SOAP, based on HTTPS to prevent transportation problems through firewalls and other devices while ensuring the safety of operations. There is extensive support for carrying out SOAP requests for the major programming languages used in web environments.

The requests are made through the HTTPS transport protocol, so you must ensure that your system is capable of correctly performing requests and managing security certificates returned by the platform to ensure proper use.

There are several operations that can be launched from the same service. The available operations are described below.

Execution of user registration in the system

Function: (add_user)

The variables required to register a user with their bank details are (in this order):

The response of the service to the request is performed by the return of an array formatted in XML with the various elements described in the following table:

If the request generates an error of some kind (incorrect signature, incorrect amount, user not found, etc) all fields will be empty, except “DS_ERROR_ID” which will contain the error code.

If the transaction is correct, the service will return the field DS_IDUSER and DS_TOKEN_USER which shall be stored by the business, associating it to the account of their customer, to subsequently make charges on their credit/debit card.

User Information

Function: (info_user)

This function will be used to confirm to the customers of the business which card will be used to make the payment. This step is optional but it is convenient to avoid mistrust.

The variables required to request information from a user are (in this order):

The response of the service to the request is performed by the return of an array formatted in XML with the various elements described in the following table:

If the request generates an error of some kind (incorrect signature, user not found, etc) all fields will be delivered empty, except “DS_ERROR_ID” which will contain the error code.

If the transaction is correct, the service will return the field DS_MERCHANT_PAN which will contain the credit/debit card masked, leaving visible only the first 6 digits and the last 4. This operation is very useful to show the customer of the business the card with which the transaction will be made.

Different languages usage:

User removal

Function: (remove_user)

This function will be used for removing a user from the account of the business.

The variables required to request removal of a user are (in this order):

The response of the service to the request is performed by the return of an array formatted in XML with the various elements described in the following table:

If the request generates an error of some kind (incorrect signature, user not found, etc) all fields will be delivered empty, except “DS_ERROR_ID” which will contain the error code.

If the transaction is correct, the service will return the field DS_RESPONSE the value of which will be 0 or empty in case of error and 1 in case of successful removal.

Execution of Charges to a user in the system

Function: (execute_purchase)

Once the user is registered in the system, charges may be made to their account by sending their credentials and data of the operation.

The variables required for making a charge to a user registered in the system are (in this order):

The response of the service to the request is performed by the return of an array formatted in XML with the various elements described in the following table:

If the request generates an error of some kind (incorrect signature, user not found, etc) all fields will be delivered empty, except “DS_ERROR_ID” which will contain the error code.

If the transaction is correct, the service will return the field DS_RESPONSE the value of which will be 0 or empty in case of error and 1 in case of successful removal.

Different languages usage:

Execution of Charges to a user in the system with DCC

Function: (execute_purchase_dcc)

Once the user is registered on the system, they can make payments with their account by sending their credentials and operation information. The DCC caseload requires that a payment process is carried out in two steps: execute_purchase_dcc, where the native currency of the card is received (in the case of the card having the same currency as the product associated with the transaction, the result will be a 1:1 conversion) and will be subsequently confirmed with the confirm_purchase_dcc method with the selected currency and the original session of the transaction.

The variables that the service requires for carrying out a DCC payment for a user registered in the system are (in this order):

The response of the service to the request is performed by the return of an array formatted in XML with the various elements described in the following table:

If the request generates an error of some kind (incorrect signature, incorrect amount, user not found, etc) all fields will be empty, except “DS_ERROR_ID” which will contain the error code.

In case of the transaction being correct, the service will restore all fields. In this case the DS_ERROR_ID field will be restored empty. The information to save for the confirmation of the operation is the DS_MERCHANT_DCC_SESSION which is a unique transaction identifier linking the purchase operation initiated on DCC. In the following step the currency must be confirmed for finalising the transaction and linking to the DCC session.

Different languages usage:

Confirmation of currency in DCC payment

Function: (confirm_purchase_dcc)

Once the DS_MERCHANT_DCC_SESSION parameter has been restored when a DCC purchase has been made, the state of the transaction will be “waiting” for the currency confirmation. The business must suggest to the client the currency in which they wish to pay (showing the conversion in real time) and when it is selected, the business must confirm the authorisation with the currency selected by the end user.

(example of interaction with the end user)

The variables required for confirming a DCC operation on the system are (in this order):

The response of the service to the request is performed by the return of an array formatted in XML with the various elements described in the following table:

If the request generates an error of some kind (incorrect signature, incorrect amount, user not found, etc) all fields will be empty, except “DS_ERROR_ID” which will contain the error code.

In case of the transaction being correct, the service will restore all fields (except DS_MERCHANT_CARDCOUNTRY which is optional) which must be stored by the business in case of a possible refund. In this case the field DS_ERROR_ID will be restored with the value 0.

Different languages usage:

Refund to User in the system

Function: (execute_refund)

By means of this function, refunds of the operations performed may be made. The user identification data and the bank authorization code will be necessary.

The variables required for making a refund of an operation are (in this order):

The response of the service to the request is performed by the return of an array formatted in XML with the various elements described in the following table:

If the request generates an error of some kind (incorrect signature, incorrect amount, user not found, etc) all fields will be empty, except “DS_ERROR_ID” which will contain the error code.

If the transaction is correct, the service will return all fields. In this case the field DS_ERROR_ID will be returned empty. The service will return the field DS_RESPONSE the value of which will be 0 or empty in case of error and 1 in case of successful refund.

Execution of subscription registration in the system

Function: (create_subscription)

The registration of a subscription implies the registration of a user in the BankStore system of PAYCOMET. This process is completely independent from the isolated charge to a customer of the business.

The variables required for registering a user with subscription are (in this order):

Example:

DS_SUBSCRIPTION_ORDER = Luis_3268314

The charge of the subscription to DS_IDUSER 32 on December 23, 2030 the system will return it as DS_SUBSCRIPTION_ORDER:

DS_SUBSCRIPTION_ORDER = Luis_3268314[23]20301223

The response of the service to the request is performed by the return of an array formatted in XML with the various elements described in the following table:

If the request generates an error of some kind (incorrect signature, incorrect amount, user not found, etc) all fields will be empty, except “DS_ERROR_ID” which will contain the error code.

If the transaction is correct, the service will return the fields DS_IDUSER and DS_TOKEN_USER which shall be stored by the business, associating it to the account of their customer, to later modify the subscription or cancel the subscription.

If the execution of the first installment is successful the system will return all the fields except DS_ERROR_ID which will be left empty.

If the execution of the first installment has an error for several reasons (balance, validity of the card, etc...), the subscription will be canceled having to create a new subscription. In this case only DS_ERROR_ID will be returned with the specific error code.

Editing a subscription in the system

Function: (edit_subscription)

If a user renews their subscription or simply wants to increase the payment of the service we offer the service of editing a subscription. In this case it will not be possible to change the currency nor the bank details of the customer of the business. The modification of the subscription involves the prior registration of a user in subscription mode in the BankStore system of PAYCOMET. This process is completely independent from the isolated charge to a customer of the business.

The variables required for editing a subscription are (in this order):

The response of the service to the request is performed by the return of an array formatted in XML with the various elements described in the following table:

If the request generates an error of some kind (incorrect signature, incorrect amount, user not found, etc) all fields will be empty, except “DS_ERROR_ID” which will contain the error code.

If the execution of the first installment is successful the system will return all the fields except DS_ERROR_ID which will be left empty.

If the execution of the first installment has an error for several reasons (balance, validity of the card, etc...), the subscription will be canceled having to create a new subscription. In this case only DS_ERROR_ID will be returned with the specific error code.

Subscription removal

Function: (remove_subscription)

This function will be used for removing a subscription from the account of the business.

The variables required for requesting the removal of a subscription are (in this order):

The response of the service to the request is performed by the return of an array formatted in XML with the various elements described in the following table:

If the request generates an error of some kind (incorrect signature, user not found, etc) all fields will be delivered empty, except “DS_ERROR_ID” which will contain the error code.

If the transaction is correct, the service will return the field DS_RESPONSE the value of which will be 0 or empty in case of error and 1 in case of successful removal.

Execution of subscription registration of a existing user

Function: (create_subscription_token)

The registration of a subscription through this process will create a subscription for a user that was already registered in the system, without it being necessary in this case to send card data again.

The variables required for registering the subscription are:

Example:

DS_SUBSCRIPTION_ORDER = Luis_3268314

The charge of the subscription to DS_IDUSER 32 on December 23, 2030 the system will return it as DS_SUBSCRIPTION_ORDER:

DS_SUBSCRIPTION_ORDER = Luis_3268314[23]20301223

The response of the service to the request is performed by the return of an array formatted in XML with the various elements described in the following table:

If the request generates an error of some kind (incorrect signature, incorrect amount, user not found, etc) all fields will be empty, except “DS_ERROR_ID” which will contain the error code.

If the execution of the first installment is successful the system will return all the fields except DS_ERROR_ID which will be left empty.

If the execution of the first installment has an error for several reasons (balance, validity of the card, etc...), the subscription will be canceled having to create a new subscription. In this case only DS_ERROR_ID will be returned with the specific error code.

Creating a user preauthorization in the system

Function: (create_preauthorization)

Once the user is registered in the system, preauthorization operations may be performed by sending their credentials and data of the operation.

The variables required for carrying out a preauthorization for a user registered in the system are the same as those described in section Execution of charges to a user in the system

Confirmation of a user preauthorization in the system

Function: (preauthorization_confirm)

Once a preauthorization operation has been performed and authorized, it can be confirmed to make the cash payment within 7 days; after that date, preauthorizations become invalid. The amount of the preauthorization confirmation can be less than, equal to or greater the original preauthorization, without exceeding 15% of the original preauthorization.

The variables required to confirm the preauthorization are:

The response of the service to the request is performed by the return of an array formatted in XML with the various elements described in the following table:

Cancelation of a user preauthorization in the system

Function: (preauthorization_cancel)

Once a preauthorization has been performed, it can be canceled within 7 days.

The variables required to cancel the preauthorization and the response elements are the same as for the preauthorization confirmation.

Confirmation of a user defered preauthorization in the system

Function: (deferred_preauthorization_confirm)

Once a card validation operation has been carried out and authorised, it can be confirmed to carry out the effective payment within the following 72 hours; after this time, the card validation lose their validity. The amount of the card validation must be exactly equal to that of the original card validation.

The variables required to confirm the card validation are the same as for confirming the pre-authorisation.

The response of the service will have the same elements as the pre-authorisation response

Cancelation of a user defered preauthorization in the system

Function: (deferred_preauthorization_cancel)

Once a card validation has been carried out, it can be cancelled within the following 72 hours.

The variables required for cancelling the card validation and the response elements are the same as for the confirmation of the card validation.

Execution of a user registration in the system by Token

Function: (add_user_token)

This method allows a user to register based on a token previously obtained through the solution BankStore JET-IFRAME

The variables required for registering a user are (in this order):

The response of the service to the request is performed by the return of an array formatted in XML with the various elements described in the following table:

Execution of Charges to a user by Reference

Function: execute_purchase_rtoken

This method allows you to run a charge based on a token previously obtained by Payment by Reference

The variables required for registering a user are (in this order):

The response of the service to the request is performed by the return of an array formatted in XML with the various elements described in the following table:

If the request generates an error of some kind (incorrect signature, user not found, etc) all fields will be delivered empty, except “DS_ERROR_ID” which will contain the error code.

If the transaction is correct, the service will return the field DS_RESPONSE the value of which will be 0 or empty in case of error and 1 in case of successful removal.

BAKSTORE IFRAME Integration

Integration via IFRAME (an independent web page located within another web page, in this case that of the PAYCOMET payment gateway and the store, respectively) is carried out via an IFRAME object with the URL address.

https://api.paycomet.com/gateway/ifr-bankstore

Below is an example of the HTML code (the request parameters have been simplified, which will be covered below):

To avoid blocking the redirections required by the payment process in some browsers with security restrictions, it is essential to indicate these parameters in the iframe declaration.

The request parameters must be formatted in the following manner:

Operations allowed:

Parameters

Execution of User Registration in the system (add_user)

This operation will register a new user in the system and make the appropriate notification.

In order to execute a successful request, it will be necessary to submit the following information:

Signature Calculation

The signature that the business will send to the gateway will be calculated in the following manner (in pseudocode):

Notification (Request to URL)

The notification of the user registration in the system will only be sent by request to the URL configured in the control panel. No notification of user registration will be sent by email.

The notification parameters are passed to the target URL using the POST method according to the following table:

Signature Calculation

Notifications will include a signature for verification of the integrity of the data. The calculation of the same is made in the following manner (in pseudocode):

Execution of charge (User implicit registration in the system) (execute_purchase)

This operation will register a new user in the system and will perform the payment operation on that user. The result of the user registration and the payment operation will be notified.

In order to execute a successful request, it will be necessary to submit the following information:

Signature Calculation

The signature that the business will send to the gateway will be calculated in the following manner (in pseudocode):

Notification (Request to URL)

The notification of the execution of a charge to a new user in the system shall be made as described Request to URL.

The notification parameters are passed to the target URL already specified in Request to URL and in case of correct user registration and payment, the following will also be returned:

Execution of subscription registration (User implicit registration in the system) (create_subscription)

The registration of a subscription implies the registration of a user in the BankStore system of PAYCOMET. This operation will register a new user in the system and will perform the operation of the first payment of the subscription. The result of the subscription shall be notified.

In order to execute a successful request, it will be necessary to submit the following information:

Signature Calculation

The signature that the business will send to the gateway will be calculated in the following manner (in pseudocode):

Notification (Request to URL)

The notification of the creation of a subscription (which implies the execution of the first payment) to a new user in the system shall be made as described for notifications in Request to URL.

The notification parameters are passed to the target URL already specified in Request to URL and in case of correct subscription registration (+ correct payment operation), the following will also be returned:

Execution of Charges to an existing user (execute_purchase_token)

This operation makes a charge to a user previously registered in the system. The result of the operation will be notified (as Type 1, Authorization).

In order to execute a successful request, it will be necessary to submit the following information:

Signature Calculation

The signature that the business will send to the gateway will be calculated in the following manner (in pseudocode):

Notification (Request to URL)

The notification of the execution of charge to an existing user in the system shall be made as described in Request to URL.

The notification parameters are passed to the target URL already specified in Request to URL and also:

Execution of subscription registration to an existing user (create_subscription_token)

This operation creates a subscription for a user already in the system and executes the operation of the first payment of the same. The result of the operation will be notified (as Type 9, Subscription).

In order to execute a successful request, it will be necessary to submit the following information:

Signature Calculation

The signature that the business will send to the gateway will be calculated in the following manner (in pseudocode):

Notification (Request to URL)

The notification of the execution of charge to an existing user in the system shall be made as described in Request to URL.

The notification parameters are passed to the target URL already specified in Request to URL and also:

Execution of Preauthorization Registration (User implicit registration in the system) (create_preauthorization)

This operation will register a new user in the system and perform the operation of preauthorization registration. The result of the user registration and the preauthorization operation shall be notified.

In order to execute a successful request, it will be necessary to submit the following information:

Signature Calculation

The signature that the business will send to the gateway will be calculated in the following manner (in pseudocode):

Notification (Request to URL)

The notification of the execution of charge to an existing user in the system shall be made as described in Request to URL.

The notification parameters are passed to the target URL already specified in Request to URL and also:

Execution of Preauthorization confirmation (preauthorization_confirm)

This operation will perform the operation of preauthorization confirmation. The result of the preauthorization confirmation operation shall be notified.

In order to execute a successful request, it will be necessary to submit the following information:

Signature Calculation

The signature that the business will send to the gateway will be calculated in the following manner (in pseudocode):

Notification (Request to URL)

The notification of the execution of charge to an existing user in the system shall be made as described in Request to URL.

Execution of Preauthorization cancellation (preauthorization_cancel)

This operation will perform the operation of preauthorization cancellation. The result of the preauthorization cancellation operation shall be notified.

In order to execute a successful request, it will be necessary to submit the following information:

Signature Calculation

The signature that the business will send to the gateway will be calculated in the following manner (in pseudocode):

Notification (Request to URL)

The notification of the execution of charge to an existing user in the system shall be made as described in Request to URL.

Preauthorization registration to an existing user (create_preauthorization_token)

This operation performs the operation of preauthorization for a user previously registered in the system. The result of the operation will be notified (as Type 3, Preauthorization).

In order to execute a successful request, it will be necessary to submit the following information:

Signature Calculation

The signature that the business will send to the gateway will be calculated in the following manner (in pseudocode):

Notification (Request to URL)

The notification of the execution of charge to an existing user in the system shall be made as described in Request to URL.

The notification parameters are passed to the target URL already specified in Request to URL and also:

Card validation and confirmation (User implicit registration in the system) (deferred_preauthorization)

This type of operation allows the merchant to validate if the card details entered are correct. In this validation, the authentication of the holder is carried out unless the business does not have a secure payment method (Type 13). To use it with REST, it is a question of calling preatuh to verify the card with the payment details and confirmpreauth to complete it, with the parameter deferred = 1 in both cases. To use it with GET you have to call deferred_preauthorization and deferred_preauthorization_confirm similarly.

In order to execute a successful request, it will be necessary to submit the following information:

Signature Calculation

The signature that the business will send to the gateway will be calculated in the following manner (in pseudocode):

Notification (Request to URL)

The card validation notification on the system will be carried out in accordance with section URL call notification.

The notification parameters are passed to the target URL already specified in Request to URL and also:

Approval after card validation (deferred_preauthorization_confirm)

This operation will carry out the card validation confirmation operation. The result of the card validation confirmation operation will be reported (Type 16).

In order to execute a successful request, it will be necessary to submit the following information:

Signature Calculation

The signature that the business will send to the gateway will be calculated in the following manner (in pseudocode):

Notification (Request to URL)

The notification of execution of a card validation will be carried out in accordance with section URL call notification.

Cancellation after card validation (deferred_preauthorization_cancel)

This operation will carry out the card validation cancellation operation. The result of the card validation cancellation operation will be reported (Type 14).

In order to execute a successful request, it will be necessary to submit the following information:

Signature Calculation

The signature that the business will send to the gateway will be calculated in the following manner (in pseudocode):

Notification (Request to URL)

The notification of execution of charges to a user by reference will be carried out in accordance with section URL call notification.

Overwriting parameters URLOK and URLKO

In addition to the parameters mentioned above for each operation type, and in a generic and transverse manner to all the operations, it is possible to overwrite the URLOK and URLKO parameters. Said parameters tell the system which URLs to redirect the result of the operation to, in terms of their success or denial.

This is available in almost all banks. If you need to use it please check this matter with PAYCOMET.

APPENDIX I – Business signature calculation

The signature will be calculated on the server of the business and shall cover the main parameters of the request to verify the integrity of the data over the Internet and the browser of the buyer.

The SHA512 encryption algorithm will be used for this purpose, which enables us to encrypt a text string. These types of one direction algorithms prevent the initial parameter from being obtained using the result.

The signature will be calculated differently depending on the function used to verify the integrity of data sent to the platform.

To facilitate the generation of the signature in languages without the necessary tools for the calculation of SHA512 algorithms, a series of libraries have been included. These files can be downloaded from the section Support->Documentation of the customer control panel.

Some of these libraries have been created by persons or entities not related to PAYCOMET. Consult the content of each file for further information.

Signature calculation depending on the function used

The signature that the business will send to the gateway will be calculated in the following manner (in pseudocode):

Function: (add_user)

Function: (info_user)

Function: (remove_user)

Function: (execute_purchase)

Function: (execute_purchase_dcc)

Function: (confirm_purchase_dcc)

Function: (execute_refund)

Function: (create_subscription)

Function: (edit_subscription)

Function: (remove_subscription)

Function: (create_subscription_token)

Function: (create_preauthorization)

Function: (preauthorization_confirm)

Function: (preauthorization_cancel)

Function: (deferred_preauthorization_confirm)

Function: (deferred_preauthorization_cancel)

Function: (add_user_token)

Function: (execute_purchase_rtoken)

APPENDIX II – OPERATION TYPES

The operation types that will be notified are detailed in the following table:

Appendix II - Advanced signature VHASH

The advanced signature VHASH aims to secure and keep the integrity of personal data information that may contain the variables sent in the IFRAME generation. This feature must be activated by PAYCOMET.

The signature that the business will send to the gateway is calculated in the following manner (in pseudocode):

SHA512( MD5( QUERY_STRING + MD5( PASSWORD ) ) )

The calculated signature must be included in the parameters of the call.