Setup & Authentication
Every POSLink integration - whether you use the Android, Windows, or iOS SDK, or integrate directly against the API - goes through the same three steps before it can take a payment: get your credentials, authenticate the merchant, and link a store and card machine. This page explains what each step means and why. Your platform's Setup page covers the exact method calls or endpoints.
1. Get your credentials
1. Access the Teya Developer Portal
- Go to partner.teya.xyz (development environment) and create an OAuth application.
- Create a Device Code Flow application to obtain your Client ID and Client Secret.
- Your Client ID and Client Secret are unique to you and your application, not to any one merchant.
- You only need one Client ID and one Client Secret to authenticate with all the merchants you serve.
- The merchant should never see them or need to enter them anywhere.
- They're used purely by your ePOS application to make requests to Teya on the merchant's behalf.
- To identify which merchant a request is for, follow the merchant connect/authentication process below - that's what tells Teya which merchant's data your app is acting on.
2. Authenticate the merchant
All Teya merchants have a Teya account (Teya ID). Before your ePOS can act on a merchant's behalf, the merchant needs to connect that account to your application - your application never sees or stores their Teya login credentials.
- Android, Windows, iOS SDKs - authentication is built into the setup call. The SDK shows its own login UI, the merchant signs in with their Teya account email, and the SDK stores and refreshes tokens for you.
- Direct API (no SDK) - you implement one OAuth 2.0 flow yourself: Code Flow with PKCE for browser-capable devices, or Device Code Flow (QR scan) for limited-input devices. See Authenticate and Connect Merchant for the full walkthrough.
3. Link a store and card machine
A merchant may have multiple stores, and each store may have multiple card machines, so your ePOS needs to let the merchant pick both:
- Get the merchant's stores and let them choose one.
- Get the card machines for that store and let them choose one (we suggest showing the serial number printed on the card machine as the identifier).
- Pairing complete - payment requests now route to the selected card machine.
- Android, Windows, iOS SDKs - this happens automatically as part of the same setup call as authentication, with built-in UI for both choices.
- Direct API (no SDK) - you call Retrieve List of Stores and Card Machines yourself, then configure the card machine for cloud communication.
Managing the device link afterwards
These operations apply once a merchant is authenticated and linked, and are common across every SDK (with platform-specific method names covered on each Setup page):
- Defer card machine selection - authenticate and link a store without picking a card machine yet, so you can link one later. Useful if you want to separate account connection from device pairing in your own UI.
- Get card machines - list the card machines available for the currently linked store, either from cache or freshly fetched from the network.
- Switch card machine - link a different card machine without repeating the full setup flow, either by showing the SDK's built-in picker or by passing a specific card machine ID.
- Clear device link only - unlink the store and card machine while keeping the merchant signed in. The next setup call re-shows store and card machine selection, skipping login.
- Clear authentication - fully sign the merchant out, which also clears the device link. The next setup call goes through login, store selection, and card machine selection again.
If your platform SDK supports a custom logger (Android, iOS), it uses these levels:
- Debug - detailed information for diagnosing issues, typically disabled in production.
- Info - general operational messages that highlight progress.
- Warning - something unexpected happened, but the app can continue.
- Error - a serious issue that caused part of the app to fail.