For Online and MOTO (Mail Order/Telephone Order) integrations, the posData object provides card networks with the "who, where, and how" of a payment. Providing accurate context ensures you qualify for E-commerce Interchange Rates, reduces fraud scrutiny, and maximizes approval rates.

Providing accurate context is not just a recommendation—it is a requirement for:

• Qualifying for E-commerce Interchange Rates: Correct classification prevents "Data Rate III" or "Standard" downgrades (which cost more).
• Reducing Fraud Scrutiny: Clearly identifying a transaction as MOTO or Recurring prevents it from being flagged by e-commerce fraud filters.
• Maximizing Approvals: Issuers approve transactions more readily when the submission method (e.g., Credential-on-File) matches the transaction intent.

Industry Best Practice: Always include posData for keyed, card-not-present, and credential-on-file transactions. Without this data, networks default to the highest-risk (and highest-cost) classification.

Transaction Classification

In a Card-Not-Present (CNP) environment, transactions are defined by the location of the cardholder and how the data is stored.

• E-commerce: Customer-initiated transactions via a web storefront or mobile app.
• MOTO: Manual entry by a merchant representative for phone or mail orders.
• Credential on File (CoF): Automated billing using a saved token (Subscriptions or Unscheduled CIT)

Alignment Rules

For all transactions in this category, the cardPresent boolean must always be set to false.

Transaction Processing Indicators

The following two fields must be used in tandem to signal the intent of the transaction to the issuing bank:

1. posData.transactionStatus → Defines the life-cycle stage (Sale vs. Auth hold)
2. authorizationIndicator → Signals if the transaction is a final billable amount

POS Data Configuration

The posData object captures the environment of the transaction. For Online and MOTO, many of these fields use standardized "Virtual" values.

Additional Parameters for transaction context to be submitted with /checkout/v3/payment endpoint

NOTE: Fields such as pos.pinCaptureCapability are excluded from these configurations as they pertain exclusively to physical Terminal (Card-Present) environments.

Best Practice JSON examples

The following configurations represent the industry-standard mapping for your API nodes.

E-commerce (One-time Purchase)

Use this when a customer enters card details on your checkout page.

"posData": {
		"cardholderPresence": "Ecom",
		"deviceAttendance": "HomePc",
		"deviceInputCapability": "KeyedOnly",
		"deviceLocation": "HomePc",
		"panCaptureMethod": "Manual",
		"partialApprovalSupport": "NotSupported",
		"transactionStatus": "Preauthorization"
},
"cardPresent": false,
"authorizationIndicator": "Undefined"

"posData": {
		"cardholderPresence": "Ecom",
		"deviceAttendance": "HomePc",
		"deviceInputCapability": "KeyedOnly",
		"deviceLocation": "HomePc",
		"panCaptureMethod": "Manual",
		"partialApprovalSupport": "NotSupported",
		"transactionStatus": "Normal"
},
"cardPresent": false,
"authorizationIndicator": "Final"

MOTO (Phone Order or Mail Order/Telephone Order)

Use this specifically for manual entry by a representative.

Note: Card networks monitor MOTO volume; using this for web traffic can lead to fines.

"posData": {
		"cardholderPresence": "Phone",
		"deviceAttendance": "VoiceAru",
		"deviceInputCapability": "KeyedOnly",
		"deviceLocation": "VoiceAru",
		"panCaptureMethod": "Manual",
		"partialApprovalSupport": "NotSupported",
		"transactionStatus": "Preauthorization"
},
"cardPresent": false,
"authorizationIndicator": "Undefined"

"posData": {
		"cardholderPresence": "Phone",
		"deviceAttendance": "VoiceAru",
		"deviceInputCapability": "KeyedOnly",
		"deviceLocation": "VoiceAru",
		"panCaptureMethod": "Manual",
		"partialApprovalSupport": "NotSupported",
		"transactionStatus": "Normal"
},
"cardPresent": false,
"authorizationIndicator": "Final"

Credential on File (Recurring/Subscription)

When processing a saved card where the customer is not present in the session:

"posData": {
		"cardholderPresence": "NotPresent",
		"deviceAttendance": "VoiceAru",
		"deviceInputCapability": "KeyedOnly",
		"deviceLocation": "VoiceAru",
		"panCaptureMethod": "Manual",
		"partialApprovalSupport": "NotSupported",
		"transactionStatus": "Preauthorization"
},
"cardPresent": false,
"authorizationIndicator": "Undefined"

"posData": {
		"cardholderPresence": "NotPresent",
		"deviceAttendance": "VoiceAru",
		"deviceInputCapability": "KeyedOnly",
		"deviceLocation": "VoiceAru",
		"panCaptureMethod": "Manual",
		"partialApprovalSupport": "NotSupported",
		"transactionStatus": "Normal"
},
"cardPresent": false,
"authorizationIndicator": "Final"

POS Entry Mode Codes

POS Entry Mode Codes are card-network–specific values used to indicate how card data was captured during a transaction. These codes are derived from POS Data fields and are primarily used by card networks for authorization, interchange qualification, and fraud assessment.

Important: Incorrect or conflicting POS Data values may result in unintended POS Entry Mode classification.

Most integrators do not need to send these codes directly, but understanding them can help with reconciliation and troubleshooting.

See also

• Sale: send posData on a one-step payment
• Authorization and Capture: send posData on an authorization
• Sale Adjustment: adjust a completed sale
• Interchange Optimization: qualify for lower interchange rates
• Card Vaulting: store credentials for Credential-on-File payments
• Payment Webhooks: subscribe to payment events