Card Present (Keyed) Transactions

Use a keyed Card Present (CP) transaction when the cardholder is physically present at the merchant location but no Priority terminal device is involved. The cashier or customer keys card data directly into your software — a kiosk, an in-store web app, or a manual-entry interface — and your API request must communicate that this is a card-present scenario through the posData and cardPresent fields.

📌
Who this is for — ISVs building in-store experiences where card data is keyed into software (kiosks, in-store web apps, attended manual entry) rather than captured by a terminal device.

What Makes a Transaction "Card Present, Keyed"

A keyed CP transaction has two defining characteristics:

Condition	Required value
The cardholder and the card are physically present at the merchant location	`cardPresent: true`
No Priority terminal device captured the card — the data was keyed into software	`posData.panCaptureMethod: "Manual"`

The defining factor is physical cardholder presence — not whether a terminal device was used. A transaction with the cardholder physically present but card data keyed manually is still card-present, and must be classified that way for correct interchange treatment.

⚠️
Setting cardPresent: false on a keyed CP transaction downgrades the interchange classification to card-not-present rates, increasing your processing cost. Always reflect physical presence accurately.

When to Use This Path

Scenario	Description
In-store kiosk	Customer enters card data into a self-service kiosk at the merchant location.
In-store web application	Customer or attendant uses a payment webpage served at the merchant's physical location.
Attended manual entry	Cashier manually keys card data while the customer and card are physically present (for example, when a chip is damaged or a magstripe is unreadable).

For card-present transactions involving a terminal device, use Path A — Priority Terminal API instead — posData is auto-populated by the terminal there, and you do not set these fields in the request.

How `posData` Differs from Terminal Transactions

	Terminal API transaction	Keyed CP transaction
`posData`	Auto-populated by the terminal	Set by your application in the request body
`cardPresent`	Auto-set	Set by your application
Card capture	Terminal hardware captures and encrypts the PAN	Your application captures the keyed PAN

Because no terminal is present to supply environmental data, your application must declare the transaction environment through posData so the card network classifies the transaction correctly.

Required `posData` Fields

Every keyed CP transaction must include the following fields:

Field	Value for keyed CP	What it tells the network
`panCaptureMethod`	`Manual`	Card data was keyed, not swiped, chipped, or tapped.
`cardholderPresence`	`Present`	The cardholder is physically at the merchant location.
`deviceAttendance`	`Attended`	A staff member is operating the entry device. (Use a different value only for true self-service kiosks.)
`deviceInputCapability`	`KeyedOnly`	The entry device supports only keyed input — no chip, NFC, or swipe reader.
`deviceLocation`	`OnPremise`	Entry happened at the merchant's physical premises.
`partialApprovalSupport`	`Supported` or `NotSupported`	Whether your application can handle a partial approval from the issuer — see Partial Approvals below.
`transactionStatus`	`Normal` for sales / `Preauthorization` for auths	Tells the network whether this is a final sale or an authorization to be captured later.
`authorizationIndicator`	`Final` for sales / `Undefined` for auths	Pairs with `transactionStatus` above.

[verify — confirm complete posData field list and accepted values with the API team before publish]

Configurations

Keyed Sale

Use this configuration when the transaction is finalized immediately. Set authorizationIndicator: "Final" and transactionStatus: "Normal".

{
  "cardPresent": true,
  "authorizationIndicator": "Final",
  "posData": {
    "cardholderPresence": "Present",
    "deviceAttendance": "Attended",
    "deviceInputCapability": "KeyedOnly",
    "deviceLocation": "OnPremise",
    "panCaptureMethod": "Manual",
    "partialApprovalSupport": "Supported",
    "transactionStatus": "Normal"
  }
}

Keyed Authorization (Preauthorization)

Use this configuration for an authorization-only transaction that will be captured later. Set authorizationIndicator: "Undefined" and transactionStatus: "Preauthorization".

{
  "cardPresent": true,
  "authorizationIndicator": "Undefined",
  "posData": {
    "cardholderPresence": "Present",
    "deviceAttendance": "Attended",
    "deviceInputCapability": "KeyedOnly",
    "deviceLocation": "OnPremise",
    "panCaptureMethod": "Manual",
    "partialApprovalSupport": "Supported",
    "transactionStatus": "Preauthorization"
  }
}

Capture the authorization later through the standard authorize-then-capture flow. See Authorize Now, Capture Later.

Partial Approvals

The partialApprovalSupport field controls how the issuer handles cards with insufficient funds for the full amount.

Value	Behavior	When to use
`Supported`	The issuer may approve a partial amount. Your application collects the remainder via another tender (split-tender flow).	When your POS can collect a second payment method on the same order.
`NotSupported`	The transaction is declined if funds are insufficient — no partial approval is returned.	When your POS cannot handle multiple tenders per order.

Example. Order total is $100; available funds on the card are $60.

With partialApprovalSupport: "Supported" — the issuer approves $60. Your application collects the remaining $40 via another payment method.
With partialApprovalSupport: "NotSupported" — the issuer declines the transaction. The merchant collects $100 via another method or cancels the sale.

Best Practices

Practice	Why it matters
Always set `cardPresent: true`	Setting it to `false` classifies as card-not-present and downgrades interchange.
Mirror the actual environment in `posData`	Each field has a downstream interchange and risk consequence. Don't copy defaults blindly.
Use `Preauthorization` when capturing later	`Normal` is for final sales only — don't use it for auth-then-capture flows.
Decide on partial approvals up front	Don't set `Supported` unless your POS actually handles split tenders.
Use Path A for terminal-based CP transactions	`posData` is auto-populated there. This page applies only when card data is keyed into software.

[verify — endpoint URL, full request body schema, and sample response pending confirmation with API team]

Where to Go Next

Path A — Priority Terminal API

For card-present transactions captured by a terminal device — posData is auto-populated.

Authorize Now, Capture Later

The auth-then-capture flow that pairs with Keyed Authorization (Preauthorization).

Choose Your Integration Path

Compare keyed entry against terminal-based paths before you build.

What Makes a Transaction "Card Present, Keyed"

When to Use This Path

How posData Differs from Terminal Transactions

Required posData Fields

Configurations

Keyed Sale

Keyed Authorization (Preauthorization)

Partial Approvals

Best Practices

Where to Go Next

How `posData` Differs from Terminal Transactions

Required `posData` Fields