> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.navipartner.com/product/retail-eft-integration-types/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.navipartner.com/_mcp/server.

# EFT integration types

> Each EFT integration is built on a common framework, implementing essential operations along with any additional functions required for specific integrations.

These integrations are categorized into two main types:

## Client-side integrations

These require a local component for communication with connected hardware, such as an EFT PIN pad linked via COM, USB, or Ethernet.

For client-side integrations, NP Retail provides **Stargate**, a hardware proxy that enables communication between the NST and the local POS machine. Stargate operates by compiling .NET DLLs that extend NP Retail’s request/response interface and storing them in the NAV database.

* These DLL assemblies are deployed to local POS machines and updated via the Stargate framework.
* To optimize performance, integration-specific graphical interfaces (GUI) should be handled locally using .NET dialogs, reducing the need for repeated communication with the NAV server.
* A *MOCK\_CLIENT\_SIDE* integration is available in NP Retail as an example for developing Stargate-based EFT integrations.
* A generic *EFTDialog.dll* assembly is also available for displaying EFT dialogs on local machines, with the source code provided upon request.

## Server-side integrations

These do not require a local component, as communication with external systems happens directly through the NAV server using C/AL and .NET interop.

For server-side integrations, standard C/AL development techniques are used to manage web service requests. These integrations rely on **Transcendence**, which dynamically loads HTML, CSS, and JavaScript at runtime. The interface continuously updates every second by checking the transaction status with the NST and the external server.

Common methods for implementing server-side integrations include:

* Long-polling HTTP requests (e.g., MobilePay)
* Frequent HTTP status checks, using standard C/AL and .NET interop
* Callback responses, which are more complex since NAV does not support open API callbacks. In such cases, an external system (e.g., Azure Functions) may be required to expose a public API for handling callbacks.

#### Examples:

* Web API-based integrations that facilitate payments through a mobile app, linking the POS to the customer’s device via an intermediate server.
* Integrations that communicate with POS hardware through an external server instead of a direct local connection.

> **Note:** Server-side integrations are generally easier to develop and maintain, as they involve fewer components on NP Retail’s side.

> Documentation for NaviPartner's NP Retail, NP Attractions, NP Hospitality, NP Store Assistant and Entria products, plus their REST APIs, built on Microsoft Dynamics 365 Business Central.