> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ionicfi.com/llms.txt
> Use this file to discover all available pages before exploring further.

# The Terminal object

> Inspect the card-present payment devices your account can use, and check whether each one is ready.

<ResponseExample>
  ```json The Terminal object theme={null}
  {
    "id": "tmr_01JEXAMPLE2K8V4N9C6M1Q7R",
    "object": "terminal",
    "location_id": "loc_01JEXAMPLE2K8V4N9C6M1Q7R",
    "label": "Front counter",
    "test_profile": "approved",
    "status": "provisioning",
    "connection_status": "online",
    "capabilities": {},
    "device": {
      "model": "…",
      "serial_number_last4": "…"
    },
    "livemode": false
  }
  ```
</ResponseExample>

A Terminal (`tmr_…`) is Ionic's record of one card-present payment device at a
[Location](/api-reference/terminal-locations). It belongs to one Merchant and mode, and it can be physical or simulated.
Physical Terminals arrive through [provisioning requests](/api-reference/terminal-provisioning);
every test account already has three ready simulated Terminals. You pass a
Terminal's ID when you [process a PaymentIntent](/api-reference/terminal-payments).

The Terminal object has three independent states: setup `status`,
`connection_status`, and `capabilities`. [The Terminal object](/concepts/terminal-object) explains each
one, how simulated and physical Terminals differ, and refund receipts. Platforms
select an authorized connected account with `Ionic-Account`; see
[In-person payments for connected accounts](/guides/connect-in-person-payments).
For the payment flow, see [Accept in-person terminal payments](/guides/in-person-payments).

## Attributes

<ResponseField name="id" type="string">
  Unique identifier for the terminal (`tmr_…`).
</ResponseField>

<ResponseField name="location_id" type="string">
  ID of the location where the terminal is used (`loc_…`).
</ResponseField>

<ResponseField name="label" type="string">
  Name for the terminal, shown in your records.
</ResponseField>

<ResponseField name="test_profile" type="string">
  Built-in deterministic outcome for this Account-owned test Terminal. Omitted for physical and non-fixture Terminals. An exact test-helper override for a PaymentIntent takes precedence.
</ResponseField>

<ResponseField name="status" type="string">
  Setup and availability state of the terminal. Only `ready` terminals can take payments.
</ResponseField>

<ResponseField name="connection_status" type="string">
  Freshness-aware connection status; stale observations are returned as `unknown`.
</ResponseField>

<ResponseField name="capabilities" type="object">
  Capability names are additive; inspect each entry's status before use.
</ResponseField>

<ResponseField name="device" type="object">
  Hardware details of a terminal.
</ResponseField>

See every field in the response of [Retrieve a Terminal](/api-reference/terminals/retrieve-a-terminal).

## Endpoints

| Endpoint | Use it for |
| - | - |
| [List Terminals](/api-reference/terminals/list-terminals) | See physical and simulated Terminals, and pick a simulated one by `test_profile`. |
| [Retrieve a Terminal](/api-reference/terminals/retrieve-a-terminal) | Read lifecycle, connection freshness, and capability readiness. |
| [Check a Terminal's connection](/api-reference/terminals/check-a-terminals-connection) | Run one read-only connection check and get the refreshed Terminal. |

## Statuses

`status` tracks setup, not reachability.

| Status | Meaning |
| - | - |
| `provisioning` | The Terminal is being set up. |
| `requires_action` | Setup needs further action. |
| `ready` | The Terminal is set up. Payments require `ready`. |
| `disabled` | The Terminal is disabled. |
| `replacing` | The Terminal is being replaced. |
| `failed` | Setup failed. |

`connection_status` is `online`, `offline`, or `unknown`. When the last
observation is too old to trust, it is reported as `unknown` and
`connection_status_stale` is `true`.

## Rules

* A Terminal can accept a payment only when its `status` is `ready` and the matching capability `status` is `ready`.
* When Ionic selects PIN debit, the `debit_pin` capability must be `ready`. Callers do not send `payment_type`; Ionic selects the payment type.
* Capability names are additive. Inspect each entry's `status` before use.
* A connection check never initiates a payment, and a failed check does not replace the last known connection state. It takes no idempotency key because each request asks for a new observation.
* Test accounts return their three built-in simulated Terminals from the list. Their `test_profile` values are `approved`, `declined`, and `delayed`.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.