Host to Host

Do you manage a business with a high number of transactions and a large number of stores, which require centralized management of internal accounts? Transbank has a good alternative for these requirements. Host to Host, a solution that involves development in the application of your store's cash registers to integrate it with the equipment provided by Transbank, connecting via a dedicated link to our servers, which will provide robustness and great speed to the payment process and information flow. .

How does it work

Host to Host requires a high level of integration, which consists of the following stages:

1. Development Your business must carry out the development according to the specifications that Transbank will give you.

2. Quality Control This process will verify that the integration development that you did complies with what we give you in the specifications, or if it requires any correction or improvement.

3. Pilot stage In a place that we agree on together, we take your pinpad host point of sale to production, where with real clients we will jointly monitor its operation, for a limited period of 2 weeks. We evaluate the results, and agree on massification, also if any adjustment is required.

4. Overcrowding We jointly build an installation plan for the points of sale.

Sales Flow on Pinpad Host:

1. The customer delivers the products or service he wants to buy to the seller.
2. The seller makes the sale in his box system.
3. The seller asks the customer how he wants to pay, cash, credit card, debit card and selects it at the checkout.
4. The box invokes the pinpad, passing it the amount of the sale and the credit or debit payment method
5. The client operates a card, selects installments if applicable, and enters his pin
6. The pinpad assembles the sales request message and delivers it to the till.
7. The box takes the message and delivers it to the merchant host and this in turn to the Transbank host (hence its name from host to host)
8. The response message travels the reverse path until it reaches the pinpad
9. The pinpad verifies the approved or rejected response and integrity of the message and returns the result to the box.
10. The box prints the sales receipts.

Equipment and connections available

Verifone vx805

Fixed Computer USB or Serial Pinpad host

Driver

These devices work with both RS232 and USB serial ports (usually plug and play), for which you may need to install a verifone driver .

This driver is compatible with the following operating systems, reported by Verifone:

• Windows 10 32/64-bit
• Windows 8/8.1 32/64-bit
• Windows 7 32/64-bit

Per PCI regulations, merchants must not use an operating system that is obsolete. It is also very important to keep your Operating System with the latest patches installed, this is mainly due to a security issue.

Verifone vx680

Mobile equipment wifi Pinpad host

Verifone e355

Mobile Device Bluetooth Pinpad host

Payment features available in HOST

• Sale Credit, with or without fees, tip or donation
• Cancellation of sale Credit.
• Sale Debit, debit with change, tip or donation
• Sales in UNOS mode (business cards)

How to start

Next, you will see the documentation associated with how to print the vouchers. You can review the Reference to see information associated with communication and commands.

Voucher

The pinpad will deliver the voucher ready to print, but it will also deliver all the data necessary for the box itself to build the voucher itself. If it is required to obtain the duplicate voucher, the box must build the voucher, without the PEL data and adding the duplicate gloss.

Considerations

Type of transactions

These are the glosses that should be displayed in the header of the voucher:

Card types

Consider that the cards issued by commercial houses under a brand such as VISA or Master are considered bank cards and not non-bank cards. Prepaid cards will be considered debit cards.

Card Brands

Print order

The idea of this voucher is that it is the only way out for any type of Transbank voucher, since it is a unique voucher, regardless of the type of transaction, the same validations are always made, to see if each field is printed or not, whether it is a voucher of credit, debit or credit cancellation.

Two copies of the voucher must always be printed, one for the merchant and one for the client. In the case of voucher with signature, if the merchant wishes, it may not print on the merchant's copy, the signature lines, customer name and rut, in the merchant's voucher it must be signed if applicable.

The print order should be:

1. TBK Award Voucher
2. TBK Customer Voucher
3. TBK Trade Voucher

Any variation to the order or format of the voucher must be authorized by Transbank

Other considerations

Some considerations in printing Transbank vouchers

1. The vouchers must contain exclusively the information requested in this manual. Any exception must be authorized and formalized by Transbank.
2. Customer name can be printed only on voucher with signature
3. Return lines should not be printed if they are not being used.
4. Donation or tip lines should not be printed if they are not being used.
5. Award vouchers should NOT be printed on self-copying paper . In the event that the client only has printers that use carbonless paper, Transbank must be notified of this situation, and it is the latter who must authorize the acceptance of this type of printing, and the functionality of online promotions may be excluded .
6. Only one copy of a prize voucher should be generated, in the face of any border condition if the voucher could not be printed, the prize is lost, the duplicate should not contain anything in this regard.
7. It is NOT possible to reprint the prize voucher or make mention of the prize on the Transbank vouchers in case of printing a duplicate.
8. The prize code and the glosses are delivered by the PINPAD after validating the response to the request.
9. The voucher printing MUST be done automatically, when the transaction is approved, not optional or manual. Should not rely on a boxed enter to release the print
10. For cases in which the cardholder's signature is necessary, the print MUST provide adequate space for said operation.
11. The start of a new transaction MUST be done ONLY at the time the printing of the voucher of the previous transaction is finished, NEVER during its printing or reprinting, since the transaction is considered completed at the time of printing the voucher or its reprinting.
12. The separation between the vouchers (transactions (original/copy), award) can be physical (cut) or delimited by dotted lines.
13. The last thing to be printed is the Transbank voucher
14. The voucher in fiscal printer goes between the glosses. “COMMENT START” and “COMMENT END”. Given the number of lines that can be printed on this type of printer, the elimination of blank lines is allowed so that the voucher can be printed correctly. Each voucher could be separated by a beginning and end of comment, this is the customer's voucher and the merchant's voucher.

Voucher of sale or cancellations

Voucher Pel and reprint

It is only allowed to print the original voucher and the PEL voucher once, if there is any problem with the printing of the original voucher, the printing must be aborted and a duplicate can be obtained.
Original:

1. PEL Voucher
2. Voucher 1 store/customer
3. Voucher 2 trade/customer

Duplicates:

1. Voucher 1 business/customer “duplicate without gloss pel”
2. Voucher 2 merchant/customer “duplicate without gloss pel”

Voucher pel 1 - Online award

This voucher should be printed only if: COMMAND H505 VOUCHER TYPE FIELD = Point of Sale Delivery

Voucher pel 2 - Online award

This voucher must be printed only if: COMMAND H505 FIELD TYPE OF VOUCHER = |2| Deferred Delivery

Voucher pel 3 - Online award

This voucher should be printed only if: COMMAND H505 VOUCHER TYPE FIELD = |3| Refund to Cardholder

ONUS Annexed

Goals

This documentation describes the way of operating, the functionality and the details of the messaging of a TRANSBANK PINPAD working under the OnUs mode.
The application of the PINPAD supposes the existence of an intelligent ECR (for example a cash register) that will send the requirements to the PINPAD, so that it can process them and deliver the results when appropriate.

Audience

To fully understand this documentation, it is necessary to have transactional knowledge and to know the functions commonly implemented in PINPADs used in banking transactions.
In particular, this manual is aimed exclusively at UNOS businesses that have their own cards and use the Transabank pinpad to read their cards, but carry out and authorize the transactions themselves.

Scope

Applies to Verifone vx805 equipment (Serial or USB connection)
Applies to Verifone e355 equipment (Bluetooth connection)

You can review the Reference to see information associated with communication and commands.

Technical specifications and special outputs

Quadrature and liquidation

This section describes the scheduling and settlement files that are delivered to the customer who uses the Special Departures service. The quadrature files (reconciliation) are flat files that contain the records of the transactions (sales and cancellation) carried out in a business within a given period. The settlement files are flat files that contain the records of the credits and withholdings made on the merchant's account within a given period.

Distribution

The scheduling and settlement files are periodically placed in an SFTP box created exclusively for the respective business, so that it can download them to its own system. The following table indicates the frequency and schedule for placing scheduling and liquidation files in the box:

Access to the box

Merchants must use an SFTP client type application available on the market to access the mailbox, some of these may be Filezilla, WinSCP, PuTTY, MobaxTerm

The name of the files of the Special Outputs (SSEE) will be generated dynamically from the data entered in the enrollment plus the process date

file_copy<Formato de Salida>_<Periodo>_<Agrupación Archivo de Salidas>_<RutComercio ó CódigoComercio>_<Tipo Conexion>_<Agrupación de Transacciones>_<Número Agrupación>

Output format

• LDN: Debit Settlement
• LCN: Credit Settlement
• CDN: Debit Quadrature
• CCN: Credit Quadrature

Period

• Daily: A daily file is generated based on the process date
• Monthly: One file is generated per month. Date associated with the penultimate business day of the month

Output File Grouping

• RE: File with unique information associated with the enrolled RUT (Generates a file)
• CC: File with information separated by merchant code of the transaction (generates a different file for each merchant code)

Connection Type

• A single file is generated. File information is not separated by connection type (when it is a single file it is not part of the name)
• When a file is generated for face-to-face and non-face-to-face connection type transactions or NP: Non-face-to-face or PR: Face-to-face

Transaction grouping

• When it is grouped by RUT it is not included in the file name
• RB: Item

Grouping Number

• It will correspond to the number of the enrolled Item.

Credit quadrature file (L3)

The structure of the records of the credit scheduling files is described in detail below. Each file has a header record ("header"), then a record for each transaction carried out in the period covered and at the end a footer record ("footer"). The credit quadrature file contains the detailed record of the financial transactions carried out with a credit card. Contains both face-to-face and non-face-to-face transactions.

Header

Footer

Detail The following table describes each of its fields:

Debit quadrature file (L3)

The debit statement file contains the detailed record of the financial transactions made with a debit card. Contains both face-to-face and non-face-to-face transactions.

Header

Footer

Detail

Credit settlement file (L5)

The credit settlement file contains a detailed record of the payments and withholdings on the merchant's account within a given period for credit card transactions.

Header

IF length of client code is less than 4

IF length of client code is greater than 3

Footer

Detail

Debit settlement file (L5)

The debit settlement file contains a detailed record of credits and withholdings on the merchant's account within a given period for debit card transactions.

Header

Footer

Detail

Grades

• All the “Process Date” fields explained in this document apply to the Process Date of the file
• The following table indicates which transactions can occur through both Host and Contingency POS, and which only through one of the two ways:

• For applications with SPDH 3.1 messaging, cancellation transactions carried out through the Host are considered as FS04 (offline), which would be represented in the file as a 220-14
• For purposes of matching transactions, only records with transaction code “10” (Purchases), “13” (WebPay) and “18” (Purchase with change) should be considered.
• For records corresponding to withheld transactions (Transaction Code “30”), only the following fields will be reported: o Transaction Date (Dktt-Dt-Tran-Dat) o Commercial Code (Dktt-Dt-Id-Retailer) o Unique Number (DSK-ID-NUM-UNICO) or Transaction Amount (Dktt-Dt-Amt-1)
• In the case of Settlement, the field (liq-vci), may contain the TSY values (correctly authenticated), since it shows only national ok authorizations. In the case of an international transaction, you will be able to see TSY and A (authentication attempt)
• In the cases of quadrature file, the field (Dktt-Dt-VCI) in addition to the previous cases, there will also be rejections with TO (TimeOut) and TSN (Transaction not authenticated).

Balance file

Considers the accounting balances pending payment for the Credit ($ and US$) and Debit products. It contains all the transactions that are processed until the accounting close (last day of processing until 2:00 p.m.) and that are pending payment (sales) or charge (withholdings).

Material available in the box

• Detail Accounting Balances Pending payment; File that contains all transactions pending payment that support the report available on the portal
• Detail transactions at the end of the month; File that presents the detail of transactions at the end of the month, that have not been processed within the month and that do not make up the balance report pending payment. A folder called CARTOLA_SALDOS will be created for each client mailbox, inside it will be all the files where their name will identify with PREFIJO_FECHA_RUT (DET_DDMMYYY_XXXXXXXXX).

DET_31102018_761349465. (.txt) COL_31122018_761349465. (.txt)

Text file structure

Balance file name structure

The file names will have a new structure, as per the following detail:

file_copy<Formato de Salida>_<Periodo>_<Agrupación Archivo de Salidas>_<Agrupación de Transacciones>_<RutEnrolado ó CódigoComercio>_<Tipo Conexion><Modo Agrupación>

<Formato de Salida> corresponds to the output format: LDN = Debit Settlement LCN = Credit Settlement CDN = Debit Settlement CCN = Credit Settlement

<Periodo> corresponds to the date in DDMMAYYY format, according to the configured frequency:

• Daily: A daily file is generated based on the process date; this is the default frequency
• Monthly: One file is generated per month. Date associated with the penultimate business day of the month

<Agrupación Archivo de Salidas> corresponds to the grouping nature:

• RE: File with unique information associated with the enrolled RUT (Generates a file)
• CC: File with information separated by merchant code of the transaction (generates a different file for each merchant code)

<Tipo Conexión> corresponds to the type of connection of the commercial codes:

• A: A single file is generated. File information is not separated by connection type (when it is a single file it is not part of the name)
• SE: A file is generated for face-to-face and non-face-to-face connection type transactions
• NP: Non-face-to-face
• PR: face-to-face

<Modo Agrupación> corresponds to the grouping mode of the commercial codes SC: Parent Branch (when it is grouped by RUT it is not included in the file name) RB: Item

Procedure link and connection Pinpad Bluetooth e355

Bluetooth Pinpad Link Flow

Pinpad Bluetooth connection E355

Power on equipment

Step 1

When turning on the equipment, it enters the main screen of the application.

Step 2

The “* 0 ” keys must be entered sequentially to enter the “Bluetooth Connection Menu.

Link devices

Step 3

In the bluetooth connection menu. Option 1> Bind Device is selected

Step 4

If a previous search was made, it will ask if you want to Search again , if you press 2> NO , it will show the devices found in the previous search.

The BT Name , which is the name that will be visible to other Bluetooth devices

Step 5

At the end of the search, it shows the devices found

Step 6

When selecting a device, this window will appear to confirm the link.

Step 7

When selecting the device, this window will appear to confirm the link.

A similar message will appear on the other device, the code that appears should be the same on both devices; In this case 648005 And we select YES and they will be linked

Step 8

Merchant must accept the Bluetooth connection.
The visit to the business must be coordinated - Contraparte Comercio

Check SPP enablement

SPP: Serial Profile interface (interface that emulates a serial port connection) must be configured if it is disabled

Step 1

In the main menu of the bluetooth manager. If it is required to enable SSP (Serial Port Profile) 3> Config MENU CONEC. BLUETOOTH SPP [Off]

Step 2

Select option 2 > SPP Server

Step 3

This screen will appear and you will return to the main menu

Delete linked equipment

Step 1

In the Bluetooth Manager Menu, select option 2> Paired Devices

Step 2

In this option, a menu will be displayed with all the devices that are linked to the e355 pinpad, the previously linked devices are registered.

Step 3

If we select the device, this menu will appear showing us 2 options. If we select YES we eliminate the link, and we return to the main menu.

Using the SDK

For the integration with the merchant's own applications, it is necessary to use the libraries included in the SDK of the Verifone e355 team in their own developments.
These are:

1. libPtr

2. libVmf
   

To facilitate the integration process, the reference to the “pinpad” resource is used, which contains functions for communication between Pinpad and the Merchant App. The structure and example code are included in the file demo_e355.zip

Import of libraries and Pinpad resource

Declaration of the main activity and PINPadTransport

Function for connection and disconnection

Example to send the command 0100 (read card to the pinpad) to the Pinpad

Function to receive the response from the Pinpad

Installation on Windows

When the link is made, 2 COM ports are created that are linked to Bluetooth. In order to review it, you must enter: Devices

Step 1

Step 2

Step 3

Step 4

Do you have any integration questions?

Join the community of integrators on Slack and share good tips helping newcomers or looking for alternative solutions. Our team is there to help you.

If you still have questions send us a message

Send us a message.

If you need to resolve any type of incident on the portal or if there is a problem with your integration that you have not been able to resolve, contact us through our form.