--- title: "Terminal API" description: "Learn about our Terminal API, including the endpoints and structure." url: "https://docs.adyen.com/point-of-sale/design-your-integration/terminal-api" source_url: "https://docs.adyen.com/point-of-sale/design-your-integration/terminal-api.md" canonical: "https://docs.adyen.com/point-of-sale/design-your-integration/terminal-api" last_modified: "2023-07-11T11:17:00+02:00" language: "en" --- # Terminal API Learn about our Terminal API, including the endpoints and structure. [View source](/point-of-sale/design-your-integration/terminal-api.md) Our Terminal API is based on the [nexo Retailer Protocol](https://www.nexo-standards.org/standards/nexo-retailer-protocol).\ See our official [Terminal API](https://docs.adyen.com/api-explorer/terminal-api/latest/overview) reference. The Adyen Terminal API lets you make payments, issue refunds, collect shopper information, and perform other shopper-terminal interactions using a payment terminal supplied by Adyen. Before you make any point-of-sale payments, it is important to understand how Terminal API works and how requests and responses are structured. ## Enable Terminal API Before you can use Terminal API in your test environment, you need to enable it: 1. Log in to your [test Customer Area](https://ca-test.adyen.com/). 2. Go to **In-person payments** > **Terminal settings** and select **Integrations**. 3. Select the option to **Enable Terminal API**. 4. Select **Save**. When you switch to your live environment, follow the same steps in your [live Customer Area](https://ca-live.adyen.com/). ## Use the correct endpoint The endpoints you need to use, and how you authenticate requests depends on how your integration connects to the Adyen payments platform: * [Local communications](#local). * [Cloud communications](#cloud). ### Local communications If your integration uses [local communications](/point-of-sale/design-your-integration/choose-your-architecture/local), API requests are made from a POS app directly to a terminal's IP address. The terminal listens for POST requests to `/nexo` on port **8443**. For example, if your terminal has the IP address **198.51.100.1** you would make API requests to: `https://198.51.100.1:8443/nexo`. If your integration uses **Android devices** and the POS app is installed on the terminal itself, you can send POST requests to either **localhost** or **127.0.0.1** from that app. Alternatively, if you assign a hostname to your terminal, you can make requests to the resolvable hostname of the terminal. You should either use [DHCP reservation](/point-of-sale/design-your-integration/network-and-connectivity/network-configuration#configuring-the-terminal-IP-address) for the terminal IP addresses, or manually configure static IP addresses. This helps to prevent connection issues when the terminal or your network reboots. To protect local communications, you need to [add Adyen's certificate](/point-of-sale/design-your-integration/choose-your-architecture/local#install-root-cert) to your POS app, and [encrypt your messages](/point-of-sale/design-your-integration/choose-your-architecture/local#protect-communications). ### Cloud communications If your integration uses [cloud communications](/point-of-sale/design-your-integration/choose-your-architecture/cloud), your POS app makes API requests to the Adyen payments platform. Our platform then forwards the request to the terminal. The endpoint you need to use depends on two things: * Whether your integration will receive transaction results synchronously or asynchronously. * Whether you are making test transactions or live transactions. #### Test endpoints Use these endpoints for all test transactions. | | Test endpoints - all locations | | -------------------- | ------------------------------------------- | | Synchronous result: | `https://terminal-api-test.adyen.com/sync` | | Asynchronous result: | `https://terminal-api-test.adyen.com/async` | #### Live endpoints When you are ready to go live, you need to switch to a live transaction endpoint. For the best performance, use an endpoint that is geographically closest to the location of your store. If you previously built an integration and are now repeating that in a new region, make sure to change the live endpoint to the one for the new region. While the regional endpoints impact the communication between your POS app and the payment terminal, the communication between your payment terminal and our back-end also depends on the data center used. To ensure that the communication between your payment terminal and our back-end is optimal, make sure to select the data center closest to your geographical location in your [Customer Area](https://ca-test.adyen.com/) under **Developers** > **API URLs** > **Select a data center**, for example **AU** for Australia. See the available regional live endpoints below or [use this overview to identify](#find-regional-data-centers) which region and URL insert applies to your terminal's location. | | Live endpoints - Australia | | -------------------- | ---------------------------------------------- | | Synchronous result: | `https://terminal-api-live-au.adyen.com/sync` | | Asynchronous result: | `https://terminal-api-live-au.adyen.com/async` | | | Live endpoints - East Asia | | -------------------- | ------------------------------------------------ | | Synchronous result: | `https://terminal-api-live-apse.adyen.com/sync` | | Asynchronous result: | `https://terminal-api-live-apse.adyen.com/async` | | | Live endpoints - Europe | | -------------------- | ------------------------------------------- | | Synchronous result: | `https://terminal-api-live.adyen.com/sync` | | Asynchronous result: | `https://terminal-api-live.adyen.com/async` | | | Live endpoints - US | | -------------------- | ---------------------------------------------- | | Synchronous result: | `https://terminal-api-live-us.adyen.com/sync` | | Asynchronous result: | `https://terminal-api-live-us.adyen.com/async` | ## Find regional data centers Find the country of your terminal's location in the table below to identify which regional data center endpoint to use. ** ### Regional data center overview | Country of terminal location | Country code | Data center region | Data center prefix | | ---------------------------- | ------------ | ------------------ | ------------------ | | **Europe/Middle East (EU)** | | | | | Austria | `AT` | EU | `live` | | Belgium | `BE` | EU | `live` | | Bulgaria | `BG` | EU | `live` | | Croatia | `HR` | EU | `live` | | Cyprus | `CY` | EU | `live` | | Czech Republic | `CZ` | EU | `live` | | Denmark | `DK` | EU | `live` | | Estonia | `EE` | EU | `live` | | Finland | `FI` | EU | `live` | | France | `FR` | EU | `live` | | Germany | `DE` | EU | `live` | | Greece | `GR` | EU | `live` | | Hungary | `HU` | EU | `live` | | Iceland | `IS` | EU | `live` | | Ireland | `IE` | EU | `live` | | Italy | `IT` | EU | `live` | | Latvia | `LV` | EU | `live` | | Liechtenstein | `LI` | EU | `live` | | Lithuania | `LT` | EU | `live` | | Luxembourg | `LU` | EU | `live` | | Malta | `MT` | EU | `live` | | Netherlands | `NL` | EU | `live` | | Norway | `NO` | EU | `live` | | Poland | `PL` | EU | `live` | | Portugal | `PT` | EU | `live` | | Romania | `RO` | EU | `live` | | Slovakia | `SK` | EU | `live` | | Slovenia | `SI` | EU | `live` | | Spain | `ES` | EU | `live` | | Sweden | `SE` | EU | `live` | | Switzerland | `CH` | EU | `live` | | United Arab Emirates | `AE` | EU | `live` | | United Kingdom | `GB` | EU | `live` | | Guernsey | `GG` | EU | `live` | | Isle of Man | `IM` | EU | `live` | | **Americas (US)** | | | | | United States of America | `US` | US | `live-us` | | Canada | `CA` | US | `live-us` | | Mexico | `MX` | US | `live-us` | | Brazil | `BR` | US | `live-us` | | Puerto Rico | `PR` | US | `live-us` | | **Australia (AU)** | | | | | Australia | `AU` | AU | `live-au` | | New Zealand | `NZ` | AU | `live-au` | | **Asia Pacific (APSE)** | | | | | Hong Kong | `HK` | APSE | `live-apse` | | Japan | `JP` | APSE | `live-apse` | | Malaysia | `MY` | APSE | `live-apse` | | Singapore | `SG` | APSE | `live-apse` | ## Get your API key You need to include an Adyen API key in the request header for: * Terminal API requests when using **cloud communications**. * Requests to other Adyen APIs. For example, for [manual capture](/point-of-sale/capturing-payments#manual-capture), [authorization adjustment](/point-of-sale/pre-authorisation#adjust-auth), and [automating terminal management](/point-of-sale/automating-terminal-management). To get an API key for your test environment: 1. Log in to your [Customer Area](https://ca-test.adyen.com/). 2. Go to **Developers** > **API credentials** and select the **Payments** tab. 3. If you do not have an Adyen API key yet, or if you want to create a new API key without affecting an existing Adyen API key that you already have, first create a "credential": 1. Select **Create new credential**. 2. In the dialog, on the **Payments** tab, select **Web service user** and enter a description for the API key. 3. Save the generated **Username**, for example **ws\_123456\@Company.\[YourCompanyAccount]**. You will need this later if you need to [manage API keys](/development-resources/api-credentials). 4. Select **Create credential**. The **Configure API credentials** page appears. 4. Alternatively, if you want to replace your existing Adyen API key with a new one, select the API credential username for your integration, for example **ws\_123456\@Company.\[YourCompanyAccount]**. The **Configure API credentials** page appears. 5. On the **Configure API credentials** page, under **Server settings** > **Authentication** select the **API key** tab. 6. Select **Generate API key**. 7. Select the copy icon **and store your API key securely in your system. 8. Select **Save changes**. When you switch to your live environment, follow the same steps in your [live Customer Area](https://ca-live.adyen.com/). Add the value of the API key to the request header using the key: **x-API-key** ## API structure Our Terminal API communicates with the terminal using JSON messages. All requests and responses have the following **message header**-**body** structure: * **Message header**: identifies the type of transaction, the terminal being used, and unique transaction identifiers. * **Body**: a request or response object, depending on the type of transaction. For example, when you make a payment request this is a `PaymentRequest` object, and when you receive a payment response this is a `PaymentResponse` object. The message header and body of Terminal API [requests](#requests) and [responses](#responses) are described in more detail below. ## Requests Each Terminal API request you make is contained in a `SaletoPOIRequest` object. In this, you need to provide a: * [`MessageHeader` object](#request-message-header). * [Request body object](#request-body) corresponding to the type of transaction. For example, this is a `PaymentRequest` object when you are making a payment, or an `InputRequest` object when you are requesting shopper input. ### Request MessageHeader In each request `MessageHeader`, specify the following: | Name | Required | Type | Description | | ----------------- | ------------------------------------------------------------------------------------------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `ProtocolVersion` | ![-white\_check\_mark-](/user/data/smileys/emoji/white_check_mark.png "-white_check_mark-") | String | Version of the Nexo protocol that Terminal API is based on.The current protocol version is **3.0** | | `MessageClass` | ![-white\_check\_mark-](/user/data/smileys/emoji/white_check_mark.png "-white_check_mark-") | Enum | This is almost always **Service**, but it can also be **Device** or **Event**. We will specify which `MessageClass` is required throughout our documentation. | | `MessageCategory` | ![-white\_check\_mark-](/user/data/smileys/emoji/white_check_mark.png "-white_check_mark-") | Enum | The type of transaction. For example, `Payment` for a payment request. We will specify which `MessageCategory` is required throughout our documentation. | | `MessageType` | ![-white\_check\_mark-](/user/data/smileys/emoji/white_check_mark.png "-white_check_mark-") | Enum | This is always **Request**. | | `ServiceID` | ![-white\_check\_mark-](/user/data/smileys/emoji/white_check_mark.png "-white_check_mark-") | String | Your unique ID for this request, consisting of 1-10 alphanumeric characters. Must be unique within the last 48 hours for the terminal (`POIID`) being used. | | `SaleID` | ![-white\_check\_mark-](/user/data/smileys/emoji/white_check_mark.png "-white_check_mark-") | String | Your unique ID for the system where you send this request from. | | `POIID` | ![-white\_check\_mark-](/user/data/smileys/emoji/white_check_mark.png "-white_check_mark-") | String | The unique ID of the terminal that you send this request to. Format: *\[device model]-\[serial number]*. For example, **P400‑123456789**.To find the POIID, see [Get the terminal ID](#get-the-terminal-id). | The example below shows the header for making a payment. **Request MessageHeader** ```JSON { "SaleToPOIRequest":{ "MessageHeader":{ "ProtocolVersion":"3.0", "MessageClass":"Service", "MessageCategory":"Payment", "MessageType":"Request", "SaleID":"POSSystemID12345", "ServiceID":"0207111104", "POIID":"V400m-324688179" }, "PaymentRequest":{...} } } ``` ### Request body The values you need to include in the request body depends on the type of transaction you are making. We provide examples and reference information for each transaction type throughout our point-of-sale documentation. ## Responses Each terminal API response you receive is contained in a `SaleToPOIResponse` object, and includes a: * [`MessageHeader` object](#response-message-header): echoes the **MessageHeader** values you provided in the [API request](#request-message-header). * [Response body object](#response-body): corresponds to the type of transaction request you made.\ For example, when you make a `PaymentRequest` you receive a `PaymentResponse` object. In a cloud integration that receives results asynchronously, you only receive an `ok` response from the Terminal API. The `MessageHeader` and response body are sent in an [event notification](/point-of-sale/design-your-integration/notifications/event-notifications) instead. ### Response MessageHeader The `MessageHeader` you receive in the response echoes the values you provided in the request. The only exception is the `MessageType`, which is **Response**. The following example shows the header you would receive in response to the [example payment request provided above](#request-message-header). **Response MessageHeader** ```JSON { "SaleToPOIResponse":{ "MessageHeader":{ "ProtocolVersion":"3.0", "MessageClass":"Service", "MessageCategory":"Payment", "MessageType":"Response", "SaleID":"POSSystemID12345", "ServiceID":"0207111104", "POIID":"V400m-324688179" }, "PaymentResponse":{...} } } ``` ### Response body The values you receive in the response body depends on the type of transaction request you made. We provide examples and reference information for each transaction type throughout our point-of-sale documentation. The response body will often include a unique [transaction identifier](#transaction-identifier), and data you can use to [generate your receipts](#receipt-data). #### Transaction identifier Every API request that creates a transaction or interacts with your money flow (such as a payment or refund) returns a unique transaction identifier in the `POITransactionID.TransactionID`: ![Transaction identifier](/user/pages/docs/03.point-of-sale/04.design-your-integration/08.terminal-api/ReferenceForOnline.svg?decoding=auto\&fetchpriority=auto) This identifier contains two values, separated by a dot: * **Tender reference**: a unique value generated by the terminal for the transaction. * **PSP reference**: a unique alphanumeric value generated by the Adyen payments platform for the transaction. If you use Adyen for [online payments](/online-payments) or an omnichannel strategy, the **PSP reference** is the equivalent of the `pspReference` that you receive for transactions made online. You should store each transaction identifier you receive, as you will need it to: * Make a refund. * Make a payment with acquired card details. * Identify the transaction in your [Customer Area](https://ca-test.adyen.com/), or in [reports](/reporting) generated by Adyen. #### Transaction identifiers for offline payments If your integration uses [local communications](/point-of-sale/design-your-integration/choose-your-architecture/local), your terminals will be able to make Offline EMV and store-and-forward transactions. When you experience a network issue, an approved payment will only generate a transaction identifier with the tender reference: ![Transaction identifier for offline payments](/user/pages/docs/03.point-of-sale/04.design-your-integration/08.terminal-api/ReferenceForOffline.svg?decoding=auto\&fetchpriority=auto) When the terminal is able to connect to the internet again, the Adyen payments platform will process the payment and generate an alphanumeric PSP reference. The PSP reference and tender reference can be found in your [Customer Area](https://ca-test.adyen.com/), and in [reports](/reporting) generated by Adyen. #### Receipt data When you make a transaction such as a payment, the payment result contains a `PaymentReceipt` object. You can add the key-value pairs from this object to the receipt that you print, display, or email to your shopper. For more information, see our [receipts documentation](/point-of-sale/basic-tapi-integration/generate-receipts). ## Get the terminal ID When you make a Terminal API request, you need to indicate which payment terminal you want to use. To do so, you populate the `POIID` field in the `MessageHeader` with the unique identifier of the payment terminal in the format *\[device model]-\[serial number]*. For example, **P400‑123456789**. There are several ways to get the unique ID (POIID) of a payment terminal: ### Get the serial number from the terminal To construct the POIID of the payment terminal: 1. Find the serial number of the payment terminal: * On the back of the payment terminal. * On the payment terminal screen under **Settings** > **Device info**. 2. Take the device model, for example, **P400**, and combine it with the serial number. 3. Add a dash between the device model and the serial number. 4. Remove any dashes from the serial number. ### Get the serial number from your Customer Area In your [Customer Area](https://ca-test.adyen.com/): 1. Go to **In-person payments** > **Payment devices**, and select the **Terminals** tab. 2. Select the payment terminal. ### Make an API call If your integration uses [cloud communications](/point-of-sale/design-your-integration/choose-your-architecture/cloud), you can get the terminal ID with an API call: 1. Make a POST [`/connectedTerminals` ](/point-of-sale/diagnostics/check-cloud-connection/#use-an-api-call)request, specifying your merchant account and optionally a store belonging to that merchant account. 2. In the response, get the `POIID` from the `uniqueTerminalIds` array.\ This array contains a `POIID` for every terminal that has a live cloud connection and belongs to the specified merchant account or store. ### Use a diagnosis request If your integration uses [local communications](/point-of-sale/design-your-integration/choose-your-architecture/local), you can get the terminal ID using a diagnosis request. 1. Make a [diagnosis request](/point-of-sale/diagnostics/request-diagnosis) with a placeholder `MessageHeader.POIID`, for example **xxxx-123456789**.\ The request will fail. 2. In the `DiagnosisResponse`, find the correct `POIID` inside the `MessageHeader`.\ This is the `POIID` of the terminal that you sent the diagnosis request to. ### Use an Android function For Android payment terminals with your app installed on the terminal: * Get the `POIID` of the terminal by calling the following function: **Get the terminal ID** ```raw Settings.Global.getString(context.contentResolver, Settings.Global.DEVICE_NAME) ``` ## Next steps [Payment flow](/point-of-sale/basic-tapi-integration) [Implement the Terminal API requests needed in a basic integration.](/point-of-sale/basic-tapi-integration) [Handle responses](/point-of-sale/error-scenarios) [Resolve Terminal API errors and handle declined payments.](/point-of-sale/error-scenarios) [Terminal API reference](https://docs.adyen.com/api-explorer/terminal-api/1/overview) [View our implementation of the nexo standard.](https://docs.adyen.com/api-explorer/terminal-api/1/overview)