Skip to main content
A Terminal (tmr_…) is Ionic’s record of one card-present payment device at a Location. It belongs to one Merchant and mode, and it can be physical or simulated. Physical Terminals arrive through provisioning requests; every test account already has three ready simulated Terminals. You pass a Terminal’s ID when you process a PaymentIntent. The Terminal object has three independent states: setup status, connection_status, and capabilities. The 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. For the payment flow, see Accept in-person terminal payments.

​
Attributes

​
string
Unique identifier for the terminal (tmr_…).
​
string
ID of the location where the terminal is used (loc_…).
​
string
Name for the terminal, shown in your records.
​
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.
​
string
Setup and availability state of the terminal. Only ready terminals can take payments.
​
string
Freshness-aware connection status; stale observations are returned as unknown.
​
object
Capability names are additive; inspect each entry’s status before use.
​
object
Hardware details of a terminal.
See every field in the response of Retrieve a Terminal.

​
Endpoints

​
Statuses

status tracks setup, not reachability. 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.