> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.runpayments.io/docs/guides/payments/card-present/overview/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.runpayments.io/_mcp/server.

# Card Present Overview

The Terminal API connects your point-of-sale (POS) application to Run Payments' P2PE-validated, card-present payment acceptance solution. Customers swipe, dip, or tap their card on an integrated card reader, and your POS receives the result — without card data ever touching your systems.

> **Note**
>
> Runner.js is not needed for card-present payments. Tokenization happens on the device.

## Two ways to take a payment

The Terminal API supports two integration paths:

* **Unified (`charge-card`):** read the card, optionally capture a signature, charge, and optionally print and/or email a receipt — in a single call.
* **Two-step (read + charge):** use `read-card` to tokenize the card on the device, then submit the token and amount to the [Payments API](/reference/payments-api/process-charge) yourself.

The API also provides per-terminal [capability flags](/docs/guides/payments/card-present/getting-started#terminal-capabilities), inline [signature capture](/docs/guides/payments/card-present/signatures-and-receipts#signature-capture), and standalone [receipt](/docs/guides/payments/card-present/signatures-and-receipts#receipts) endpoints for printing and emailing.

### Choosing an integration path

|                             | Unified — `charge-card`                         | Two-step — `read-card` and Payments API                                                                                      |
| --------------------------- | ----------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| **Calls to take a payment** | One call                                        | A Read request, then a separate Charge request                                                                               |
| **Signature capture**       | `include_signature`                             | `include_signature`                                                                                                          |
| **Print receipt**           | `print_receipt` inline                          | Call `print-receipt` after charging                                                                                          |
| **Email receipt**           | `send_receipt` and `email` inline               | Call `/api/v1/send_receipt` after charging                                                                                   |
| **Result**                  | Charge response (+ `signature`, `stage_errors`) | Card `token`, `name`, `expiry`, `amount` (+ `signature`)                                                                     |
| **Best for**                | Most POS integrations                           | Integrations that need to act between read and charge (e.g., custom charge logic, tipping, or vaulting via the Payments API) |

## Supported devices

The Terminal API is compatible with the following integrated card readers:

| Family   | Models               | Signature     | Printer       |
| -------- | -------------------- | ------------- | ------------- |
| Clover   | Flex, Mini           | Supported     | Supported     |
| Clover   | Compact, Pocket      | Supported     | Not supported |
| Ingenico | Link 2500, Lane 3600 | Not supported | Not supported |
| Ingenico | Lane 7000, Lane 8000 | Supported     | Not supported |

> **Tip**
>
> Always drive feature availability from the live `capabilities` object on each terminal (see [Terminal capabilities](/docs/guides/payments/card-present/getting-started#terminal-capabilities)) rather than hard-coding by model.

## Expected flow

#### Get a UAT device

Work with Integration Delivery ([integrations@runpayments.io](mailto:integrations@runpayments.io)) to order a UAT device and assist with provisioning.

#### Authenticate

Authenticate using your Run Developer API credentials. See [Getting Started](/docs/guides/payments/card-present/getting-started).

#### Check terminal capabilities

List your terminals and read their capabilities to decide which features (signature, printing) to offer.

#### Process a transaction

Either:

* **Unified:** call `charge-card` and retrieve the result by polling or WebSocket, **or**
* **Two-step:** call `read-card` and retrieve the result to collect the tokenized card data from the device, then run a [Charge](/reference/payments-api/process-charge) request with the Payments API.

#### Deliver receipts

Print receipts on the device and/or email them — at charge time or afterward.

#### Reconcile

Leverage [webhooks](/docs/guides/webhooks/overview) or the [Reporting API](/docs/get-started/report-transactions) to reconcile data.

## In this guide

#### [Getting Started](/docs/guides/payments/card-present/getting-started)

Environment, authentication, and terminal capabilities.

#### [Interactions & Status](/docs/guides/payments/card-present/interactions-and-status)

Polling, WebSockets, cancelling, and sessions.

#### [Unified Charge Workflow](/docs/guides/payments/card-present/unified-charge-workflow)

Run `charge-card` and handle declines and `stage_errors`.

#### [Signatures & Receipts](/docs/guides/payments/card-present/signatures-and-receipts)

Capture signatures and print or email receipts.

#### [Surcharging on Device](/docs/guides/payments/card-present/surcharging-on-device)

Card-present surcharging for enrolled merchants.

#### [Endpoints & Errors](/docs/guides/payments/card-present/endpoints-and-errors)

Endpoint summary, response codes, and error messages.

> Accept card-present payments from your POS with the Run Developer Terminal API.