Run on the JVM

If your desktop ePOS app runs on the JVM, you can add the Teya PosLink SDK to your app as a normal library dependency and call it directly.

Is this page for you?

What you skip

The Teya Integrations App exists because we cannot assume a desktop ePOS app runs on a JVM. If yours does, you don't need it — or any of the integration work that comes with it:

• No subprocess to launch and keep alive.
• No JSON-RPC messages to build, send and parse.
• No public certificate to verify.
• No child-process lifecycle to tie to your own.

Your code calls SDK functions directly, the same way our Android and iOS SDKs work.

Requirements

Add the dependency

The artifact name ends in the platform you ship to, so that the choice is explicit and identical on every build machine — including CI running a different OS to the one you ship to:

com.teya.epos:unified-sdk-poslink-jvm-windows-x64

Replace SDK_VERSION below with the latest version:

<repositories>
    <repository>
        <id>google</id>
        <url>https://maven.google.com</url>
    </repository>
</repositories>

<dependencies>
    <dependency>
        <groupId>com.teya.epos</groupId>
        <artifactId>unified-sdk-poslink-jvm-windows-x64</artifactId>
        <version>SDK_VERSION</version>
        <type>pom</type>
    </dependency>
</dependencies>

repositories {
    mavenCentral()
    google()
}

dependencies {
    implementation("com.teya.epos:unified-sdk-poslink-jvm-windows-x64:SDK_VERSION")
}

Google's Maven repository is needed alongside Maven Central because a few of the SDK's dependencies are only published there.

Other platforms

Windows x64 is the platform we support in production. These also exist and behave the same way — use them if you develop or test on another machine:

Start from the sample

The quickest way in is our Java sample app — a working desktop ePOS app built on the dependency above, covering both integration flows end to end:

• Sale — browse a product catalogue, add items to a basket, take a payment with an optional tip, and print a receipt.
• Pay at Table — terminals drive the bill and the payment for open tabs, and the app responds to the events.

View the Java sample on GitHub

Its README covers running it: set your clientId and clientSecret, then ./mvnw javafx:run.

Where the functions are documented

The JVM SDK is the same Kotlin/Java API as our Android SDK, so the Android guides document every function you will call — setup, payments, payment states, tips, refunds, custom receipts and Pay at Table. Every code sample there has a Kotlin and a Java tab, so switch to whichever you are writing.

Two things to keep in mind while reading them:

• Skip their Getting Started page — the dependency setup above replaces it.
• Ignore the Android-specific bits, such as minSdkVersion and Gradle plugin requirements. Everything about the SDK's own API applies to your JVM app as written.

For signatures and types, the SDK API reference covers the whole SDK. The poslink module's callback flavour is the one to read if you are writing Java.