Integration options

LAN integration

LAN integration allows the Merchant to activate the POS directly from the ECR, sending a message from the ECR to the IP address of the POS. For new EFTPOS based with Linux OS is required a port over 1024.

Some terminals have also USB/RS232 ports, but the usage is deprecated, as it might be not available on new products in the future.

The POS interacts with the Cardholder reading the payment card and send the authorization request to NEXI.

Is up to you to define if the POS prints the payment receipts at the end of the transaction or to integrate the payment receipts in the tax receipts printed by ECR.

Integration test kit

The Merchant can request through his commercial contact (i.e. Bank, Nexi or ISV) the supply of a test kit composed by a terminal and a kit of cards, to test the integration made by the Developer.

Go-live

The Merchant subscribes the POS and acquiring contract with Nexi through his commercial contact.

Nexi technical support team contacts the Merchant for checking the compatibility between ECR and POS, and for gathering all POS configuration need for the activation (IP, PORT, etc.).

You may require the following POS configuration:

• ECR Integration and standalone usage – Payments can be requested by the cash register o manually through the user interface of the POS terminal
• ECR Integration only – Payment can be requested only by the ECR When all the information is available, NEXI performs the configuration activity onsite or remotely.

Basic integration

Terminal Status

ECR verifies Eft-POS status by Terminal Status.

Terminal Status command guarantee the connection between ECR and EFT-POS.

Payment

Basic payment

ECR requests a Payment EFT-POS by command Payment, the payment amount is filled.

EFT-POS will process transaction and response with the transaction Result. For detail see Payment (command “P” or “X”).

Below is reported a few information useful to understand the protocol.

Date and time

EFT-POS:

• is synchronized with Host System
• Displays local data and time
• Via Lan Integration protocol, ECR receives the date and time of the Host System

Payment Type: The response field reports the type of card processed. For historical Reason:

• Debit Card is used to refer PagoBANCOMAT Card
• Credit Card is used to refer International Card

Aquirer ID: The response field reports Acquirer code that process transaction. Warning This Acquirer Id code may be different for each Scheme/Acquirer.

Below is shown the basic payment flow:

Payment with Receipt manage by ECR and Additional TAG

In this use case, it is required that the receipt is printed on the ECR and not on the POS, and with the execution of a Payment and simultaneous sending of additional TAGs to GT, no Addition TAGs received from GT.

LAN Integration requires managing of multiple commands.

The request consists of:

• instruct the POS on the receipt management mode (command E, management mode 1)
• the Payment function must be started by specifying the amount and advice of presence Additional TAGS (command “P”).
• data relating to Additional Tags (U command).

The response consists of:

• Transaction result via 'E' message (protocol document link)
• Receipt via Message/Messages 'S' (protocol document link)

Below is reported a few information useful to understand the protocol.

Receipt

• Receipt is formatted by the POS following the requirements of the Payment Schemes.
• The receipt, if requested by ECR, is sent pre-formatted.
• The ECR will print the receipt “as is”.

Warning

• NEXI can change the format of the receipt data without communication.
• Receipt could be transmitted by more than one ‘S’ message. It is up to ECR to concatenates all the ‘S’ messages.

In the below example, the receipt is sent through 2 'S' messages:

Exception Management

Lost Payment Response

• The exception can rise for different reason, i.e. connection drop, EFT-POS issues, ECR timeout, etc.
• The protocol provides the command “G” that can be used to retrieve last transaction result.

Warning

• It is not available unique identifier between the pending request with last transaction result.

NAK usage

• NAK is used to control the reception and retransmission of messages, a retransmission attempt is expected for a maximum of 3 times (Communication Protocol)
• NAK is also returned in the case of commands not managed by POS.

Reprint Receipt

• ECR requests Reprint via command “R”.

Reversal Last Transaction

Eft-Pos allows the cancellation of the last transaction performed. The purpose of the transaction is the management of any operational errors (i.e. incorrect amount entry).

The functionality requires reading the card data in the same way as the previous transaction.

Warning STAN management is recommended.

Total and Close Session

EFT-POS records the totals of the transactions managed; also the Host records the totals. The Local and Remote Total are reset by Close Session operation.

ECR retrieved Local and Remote Total via command “T” putting in evidence any difference between locale and remote totals.

Functions for Hotel and Car rentals

For hotel and car rental, Nexi has a set of specific functions to allow optimal management of payment processes in compliance with the requirements of the payment schemes and the needs of the Merchant.

These functionalities are partially available using LAN Integration.

• Preauthorization: requested for the estimated value of the service in order to block the plafond of the Cardholder
• Incremental Authorization: requested to block an additional amount during the execution of the contracted service
• Pre-authorization capture: requested to debit the Cardholder for the final amount service.
• Card verification: requested to validate the card presented by the Cardholder.
• No-Show (not available via LAN Integration): requested to debit the Cardholder for guaranteed reservation.
• Delayed Charges (not available via LAN Integration): requested to debit the Cardholder after the payment of the original service (i.e. for fine o damages in car rental sector).
• Pre-authorization void (not available via LAN Integration): requested to unblock the card plafond.
• Reversal of last transaction: requested for preauthorization request and capture.

Preauthorization

Using LAN Integration, ECR initiates the preauthorization request with the estimated amount of the service.

The terminal processes the transaction and gives back the result with some identification data of the transaction.

In case of positive result, ECR receives the unique code of the preauthorization, instead, in case of negative result, a response code with the description of the error, if available.

Incremental Authorization

Using LAN Integration, ECR initiates the Incremental Authorization request using the unique preauthorization code received in the original preauthorization request and the additional estimated amount of the service.

For the details, please see command “i” specification in API section.

Preauthorization Capture

Using LAN Integration, ECR initiates the Incremental Authorization request using the unique preauthorization code received in the original preauthorization request and the final amount of the service. For the details, please see command “c” specification in API section.

Tokenization

Tokenization allows to save Cardholder’s payment data, after signing a debit mandate contract proposed by the Merchant, to manage the following use cases:

• Recurring Payments
• Unscheduled Recurring Payments
• OneClick Payments

Merchant can activate Tokenization only using LAN Integration with the following transactions:

• Payment
• Card Verification
• Preauthorization

Additional Tags must be valued, as described in API specification, by the ECR specifying a unique code that identify the contract signed by the Cardholder.