# .NET library

The Tyro Terminal Adapter (TTA) is a simple .NET programmable interface for integrating a POS
with Tyro terminals, letting the POS call it to perform purchase and refund transactions. During
a transaction, the POS operator is presented with a window showing its progress on the terminal;
the TTA manages all communication with the terminal to perform it.

**TTA V2** is the current integration, built on modern .NET (Core, supporting .NET 6, 7, and 8). It
uses a lightweight NuGet-based model — no local installation is required, and dependencies are
bundled with the POS application.

**TTA V1** (also called "legacy TTA") is based on the .NET Framework and supports up to .NET
Framework 3.5 (including 2.0 and 3.0). It relies on a locally installed library (via the Global
Assembly Cache), which can introduce environment and dependency considerations. Contact
[integrationsupport@tyro.com](mailto:integrationsupport@tyro.com) if you need assistance with
TTA V1.

In TTA v2, there's a headless capability, letting POS vendors implement their own UI rather than
using the default one Tyro provides — see [Headless mode](/docs/in-person-payments/pay-in-person/integration-guide/net-library/headless-mode).

## Integration overview

A POS system communicates with a Tyro terminal via the Tyro Integration Server, as shown below —
the same secure, reliable network connection the terminal uses to perform financial transactions
also facilitates integration. This style of integration is called "Web Integration". The server
acts as a proxy for all requests, which simplifies terminal deployment and lets Tyro expose
additional functions — such as richer reporting — to the POS system.

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

At a high level, the operations the TTA exposes to a POS are:

- **Purchase** (with optional cashout) — see [API reference](/docs/in-person-payments/pay-in-person/integration-guide/net-library/api-reference) for the data
that can be sent at the start of a purchase.
- **Refund** — see [API reference](/docs/in-person-payments/pay-in-person/integration-guide/net-library/api-reference) for the data that can be sent at the
start of a refund.


From the POS system's perspective, a transaction goes like this: the POS starts a transaction
using the Tyro software, then waits for it to finish, either because the transaction completed
successfully and the result is known (approved, declined, etc — see
[API reference](/docs/in-person-payments/pay-in-person/integration-guide/net-library/api-reference) for what's available at this point), or because a fatal error
occurred communicating with the terminal, so the EFTPOS transaction's result on the terminal
couldn't be determined (same reference).

While the POS waits, the TTA displays a window to the operator with updates on the transaction in
progress, and the opportunity to control it in some way — removing the need for the operator to
interact directly with the terminal. If the POS has elected to manage EFTPOS receipt printing
itself, it also receives notification when receipts are available to print or store during this
time.

All new POS integrations are required to incorporate integrated receipts, since not all Tyro
terminals have integrated printers.

### The .NET Core model

In the .NET Core world, there's no Global Assembly Cache for libraries any more. Any libraries a
.NET Core application uses are pulled down as a NuGet package and shipped as part of the
application — Microsoft wants .NET applications to be self-sufficient, reducing errors from
missing or incorrect dependencies. The tradeoff: Tyro loses the ability to enforce which version
is used, since an updated TTA requires the POS application to be rebuilt with the new package and
re-released. The old POS application keeps running fine with the old TTA library in the meantime.

## Deprecated components

The .NET Core model significantly streamlines the solution by removing:

- **Registry usage** — registry was previously used for two kinds of settings: per-user settings
like pairing info, and global settings like the integration server URL. Per-user settings have
moved to a user config file at `%UserProfile%\AppData\Local\Tyro\config.json`; global settings
have moved to an online `settings.json` file hosted by Tyro. All registry usage in the codebase
has been cleaned up.
- **Installer** — no longer needed, since no installation is required to use TTA functionality on
the client machine. All WiX Toolset installer projects have been removed from the codebase.
- **Filewatcher** — no longer supported. It required admin rights to see and turn on in the
Configurator app, which is now started via a thin client interface by the POS application
(which won't have admin access), and admin rights to modify the registry so it runs on OS
startup, which is no longer possible.
- **RMS COM** — no longer supported, since it required a COM installation.
- **Updater & telemetry** — no longer needed, since both required installing Windows services.
For the updater specifically, it's also because the online model is the new way of enforcing
updates.
- **Compact Framework** — support is removed, since Compact Framework no longer exists. The
codebase previously had significant conditional logic (`#if COMPACT_FRAMEWORK`) and a dedicated
build for it; both are now gone.