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.

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.

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.