# JS library

A Tyro terminal acquires financial transactions and communicates with Tyro over an IP network.
This simple infrastructure lets Tyro terminals integrate with POS systems: the terminal maintains
a connection to the Tyro servers, and integration information passes to and from the terminal over
that connection, as shown below.

![Tyro IP-based integration infrastructure](/assets/ip-infrastructure.b4c23961645b14a84df97697e4760bff4a807f2fd8ea58dd1cf8813949185051.68286485.png)

The Tyro Integration Client (iClient) is a JavaScript library that the POS/PMS program includes in
its code on the payment page. It presents the POS software with a set of easy-to-use functions
covering the wide variety of operations and requests iClient supports, using JSON objects to
define request parameters and response payloads (the latter delivered via callbacks).

Once invoked, iClient manages communication between the POS and the Tyro terminal, providing
status updates on the current operation being performed for the transaction (e.g. "Processing
Transaction", "Enter PIN", "Signature OK?") as well as the result payload once the transaction
completes. If the transaction encounters an error, the error message and code are displayed for
the user's reference too, as shown below.

![Tyro UI](/assets/ui.fc19fb7f119ecb5ae8a3593e491b3371d48713265fe60103bc2b396f51b85b19.68286485.png)

There are two versions of the JS library: the **headful** library, which comes with a ready-made
Tyro transaction reporting user interface (shown above), and the **headless** library, where the
POS is responsible for developing a transaction reporting interface of its own, in line with the
features and performance of the ready-made one.

Use the headful library unless there's a particular reason the POS program can't generate an
iframe or a modal — reach out to the POS Integration Support team for confirmation before
developing against the headless library.

## Benefits of the headful library

1. It's quicker and easier to develop with, since the POS doesn't have to develop its own
transaction processing interface.
2. Quicker review and certification time, since the transaction processing user interface doesn't
have to be tested and reviewed for compliance with the criteria.
3. Merchants get a proven, field-tested interface with the required error-handling and reporting
mechanisms for fuss-free operation and easy troubleshooting.


When iClient is invoked, the headful library displays a modal iframe in the centre of the screen
and presents the POS operator with the transaction's details as it progresses. With the headless
library, the POS program has to generate, present, manage, and persist that modal itself for the
course of the transaction, and ensure any status, result, and error messaging displayed is taken
directly from the iClient API response.

## Features supported

The JS library is a feature-rich API supporting the following Tyro Payments features:

- Terminal configuration (pairing, terminal information, and iClient logs)
- Payment, cashout and refund
- Continue last transaction
- Integrated receipts
- Surcharge
- Split payments
- Reports
- Bar tabs
- Tipping
- Manual settlement
- Pre-authorisation
- Multi-merchant
- Integrated Private Health Fund claiming
- Integrated Medicare Easyclaim


See the Features section for how each feature is implemented across integration paths.

## Native wrappers

POS applications that need to embed a WebView directly, rather than a browser page, can use a
native wrapper around the JS library instead of embedding it directly: [Android](/docs/in-person-payments/pay-in-person/integration-guide/js-library/android)
(Kotlin) or [iOS](/docs/in-person-payments/pay-in-person/integration-guide/js-library/ios) (Objective-C). Both expose the same functions, parameters and
callbacks as the JS library itself.