> For the complete documentation index, see [llms.txt](https://docs.omni.integratedcommerce.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.omni.integratedcommerce.io/payments/card-present.md).

# Card present

In-person payments on Verifone T650c and T650p terminals.

Card Present transactions are processed through Verifone T650c (countertop) and T650p (portable) Android-based payment terminals.

## Supported transaction types

The API supports the following Card Present transaction types:

* **Authorization** - Verification with the Issuer if the card is valid for payment. The authorization amount is reserved, but not captured/settled.
* **Capture** - Complete a previously authorized transaction. The cardholder is billed for the transaction, and the transaction is settled to the merchant.
* **Sale** - Combined authorization and capture in a single step.
* **Refund** - Process reversal of a previous sale transaction (automatically performs a void if the transaction is in the current batch, or a refund if already settled).
* **Void** - Cancel a previously completed transaction (sale, authorization or capture) if it is still in the current batch (typically same day).

## Endpoints

| Operation                      | Endpoint                           |
| ------------------------------ | ---------------------------------- |
| Sale                           | `POST /transactions/physical-sale` |
| Authorization                  | `POST /transactions/physical-auth` |
| Capture                        | `POST /transactions/capture`       |
| Refund                         | `POST /transactions/refund`        |
| Void                           | `POST /transactions/void`          |
| Create a token from a terminal | `POST /payment-methods/physical`   |

Capture, refund, and void are shared across channels - the original transaction determines the channel.

## Terminal-specific result codes

Because the transaction runs on physical hardware, a request can fail for reasons that have nothing to do with the card. These surface as transaction `resultCode` values:

| Code   | Condition                                                                                                                                |
| ------ | ---------------------------------------------------------------------------------------------------------------------------------------- |
| `1003` | The payment terminal is busy or unavailable. If this persists, close and re-open the Payment Application on the terminal, or restart it. |
| `1005` | The specified terminal could not be found.                                                                                               |
| `1010` | The transaction request is pending to become a transaction.                                                                              |
| `3002` | The payment terminal could not find the related transaction.                                                                             |
| `3005` | Power off the terminal, wait one minute, and retry. If the error persists, contact support.                                              |
| `3006` | The terminal is low on battery.                                                                                                          |
| `3009` | Network connectivity issues with the terminal. Restore connectivity and try again.                                                       |
| `3010` | The transaction took too long and was cancelled by the application.                                                                      |

See [Errors and rate limits](/get-started/errors-and-rate-limits.md) for the full picture.

## Testing

Card Present testing needs physical test cards with real chips, stripes, and contactless antennas. See [Test cards](/going-live/test-cards.md#physical-test-cards-for-card-present-transactions).