h1
Every transaction falls into one of two categories, based on how the card is presented: **Card Present** and **Card Not Present**.

Details about the capture can be reported.
The `readingMethod` field specifies whether the terminal reads the card automatically or the cardholder keyed in the details manually.
This capability is specified from `POST /v2/pos/transactions`.
This is further refined with `cardDataSource`, returned from `GET /v2/pos/transactions/{posTransactionId}` and `GET /v2/transactions/{transactionId}`.
The field `cardDataSource` indicates a more granular type and reports what the terminal or gateway actually determined happened.

Card networks may also apply different interchange rates to card present and card not present transactions.

h3
Card Present (CP)
A card present transaction occurs when the physical card is read at a point of sale.
The card can be tapped for a contactless read, inserted with a EMV chip read, or swiped using its magnetic strip.
Flute represents this pattern through *POS Transactions* endpoints, tap to pay through the iOS SDK, or a terminal deeplink through the Android Terminal SDK.

Regardless of the read or input method, the transaction is still card present because it happens on a physical terminal.

h3
Card Not Present (CNP)
A card not present transaction occurs when no physical card is read at a point of sale.
The cardholder supplies the card number, expiration date, and the card's security code (CVV).
Card not present requests should also include the cardholder's billing address so Flute can perform AVS (address verification service) to reduce fraud.

Common examples include online purchases, phone orders, and mail orders.
Flute represents this pattern through the *Transactions* endpoints.
These endpoints accept raw card data or a saved payment method, with no terminal involved.
The `Internet` value of `cardDataSource` marks a card not present entry.

Card not present transactions carry higher fraud risk than card present transactions.