Card Present Transactions
Submit card-present payment data to Priority across four entry methods — EMV chip, NFC contactless, magstripe swipe, and manual keyed entry — using the shared /payment endpoint.
Card-present (CP) transactions are payments where the cardholder is physically present at the merchant location. Priority supports four ways to capture and submit card data for CP transactions — chip insert, contactless tap, magstripe swipe, and manual keyed entry. All four hit the same /payment endpoint; what differs is the shape of the card data in the request body.
Who this is for — ISVs submitting captured card data to Priority's Checkout API, regardless of which integration path (Vendor-Direct, custom reader, or keyed entry interface) captured the data.
The Four Entry Methods
Customer inserts a chip card into an EMV-capable reader. The reader returns encrypted TLV data, which you submit as emvData + emvDataKsn.
Customer taps a contactless card or mobile wallet (Apple Pay, Google Pay, Samsung Pay) on an NFC reader. Same field shape as EMV.
Customer swipes a magstripe card through a supported reader. You submit the full magstripe string as cardAccount.magstripe.
Cashier or customer keys card data into software (kiosk, in-store web app, manual entry). You set cardPresent: true and populate posData.
What All Four Have in Common
| Aspect | Detail |
|---|---|
| Endpoint | POST /payment (Checkout API) |
| Authentication | Basic auth — Base64-encoded username:password in the Authorization header |
| Content type | application/json |
| Optional response param | echo=true returns the full payment object without a follow-up GET |
| Merchant identifier | merchantId in the request body |
| Sandbox behavior | Valid-format card numbers approve by default; use documented test cards for declines |
| Settlement | Same merchant account / MID as your card-not-present transactions |
What Differs by Entry Method
| Entry method | How data is captured | Field shape in cardAccount | Reader requirement |
|---|---|---|---|
| EMV Chip | Chip card inserted into EMV reader | emvData (C2 tag) + emvDataKsn (C0 tag) | EMV-capable reader, injected with PPS private key |
| NFC Contactless | Card or wallet tapped on NFC reader | emvData (C2 tag) + emvDataKsn (C0 tag) — same as EMV | NFC-enabled reader, injected with PPS private key |
| Swiped Card | Card swiped through magstripe reader | magstripe — full magstripe string | Supported magstripe reader |
| Card Present (Keyed) | Card data keyed into software | cardPresent: true + posData object (no encrypted card data field) | No reader required — software entry |
EMV and NFC share the same field shape because both produce TLV-encoded EMV-style data. The capture method differs (insert vs. tap); the submission shape is identical.
When to Use Each Method
| Choose... | When... |
|---|---|
| EMV Chip | The card has a chip and the merchant has EMV-capable hardware. Default for in-person CP whenever both conditions are met. |
| NFC Contactless | The customer uses a contactless card or mobile wallet and the terminal has NFC. Fastest customer experience. |
| Swiped Card | The card has no chip, the reader is magstripe-only, or the EMV chip read fails and the terminal falls back to swipe. |
| Keyed | No reader is present — software-based entry on a kiosk, in-store web app, or attended manual entry. |
How These Map to Integration Paths
The four entry methods are about how card data is shaped in the API request. The integration paths are about who drives the terminal. The two are orthogonal — pick one of each.
| Integration path | How card-present data reaches /payment |
|---|---|
| Priority Terminal API | You don't call /payment directly. The Terminal API workflow handles EMV / NFC / Swipe via the terminal, then you retrieve the final payment record via the Checkout API. |
| Vendor-Direct | Your application uses the vendor SDK (e.g., PAX VTX-HC, Clover SDK) to capture card data, then submits it to /payment using the field shapes above. |
| Standalone | The terminal processes payments on its own — no /payment call from your side. |
| Keyed CP | Your software captures keyed PAN data and submits it directly to /payment with the keyed field shape. |
Where to Go Next
Submit chip-card encrypted data to /payment.
Submit tap-to-pay data — including mobile wallets — to /payment.
Submit magstripe data to /payment.
Submit manually-keyed CP data with the right posData classification.
Card-present (CP) transactions are payments where the cardholder is physically present at the merchant location. Priority supports four ways to capture and submit card data for CP transactions — chip insert, contactless tap, magstripe swipe, and manual keyed entry. All four hit the same /payment endpoint; what differs is the shape of the card data in the request body.
Who this is for — ISVs submitting captured card data to Priority's Checkout API, regardless of which integration path (Vendor-Direct, custom reader, or keyed entry interface) captured the data.
The Four Entry Methods
Customer inserts a chip card into an EMV-capable reader. The reader returns encrypted TLV data, which you submit as emvData + emvDataKsn.
Customer taps a contactless card or mobile wallet (Apple Pay, Google Pay, Samsung Pay) on an NFC reader. Same field shape as EMV.
Customer swipes a magstripe card through a supported reader. You submit the full magstripe string as cardAccount.magstripe.
Cashier or customer keys card data into software (kiosk, in-store web app, manual entry). You set cardPresent: true and populate posData.
What All Four Have in Common
| Aspect | Detail |
|---|---|
| Endpoint | POST /payment (Checkout API) |
| Authentication | Basic auth — Base64-encoded username:password in the Authorization header |
| Content type | application/json |
| Optional response param | echo=true returns the full payment object without a follow-up GET |
| Merchant identifier | merchantId in the request body |
| Sandbox behavior | Valid-format card numbers approve by default; use documented test cards for declines |
| Settlement | Same merchant account / MID as your card-not-present transactions |
What Differs by Entry Method
| Entry method | How data is captured | Field shape in cardAccount | Reader requirement |
|---|---|---|---|
| EMV Chip | Chip card inserted into EMV reader | emvData (C2 tag) + emvDataKsn (C0 tag) | EMV-capable reader, injected with PPS private key |
| NFC Contactless | Card or wallet tapped on NFC reader | emvData (C2 tag) + emvDataKsn (C0 tag) — same as EMV | NFC-enabled reader, injected with PPS private key |
| Swiped Card | Card swiped through magstripe reader | magstripe — full magstripe string | Supported magstripe reader |
| Card Present (Keyed) | Card data keyed into software | cardPresent: true + posData object (no encrypted card data field) | No reader required — software entry |
EMV and NFC share the same field shape because both produce TLV-encoded EMV-style data. The capture method differs (insert vs. tap); the submission shape is identical.
When to Use Each Method
| Choose... | When... |
|---|---|
| EMV Chip | The card has a chip and the merchant has EMV-capable hardware. Default for in-person CP whenever both conditions are met. |
| NFC Contactless | The customer uses a contactless card or mobile wallet and the terminal has NFC. Fastest customer experience. |
| Swiped Card | The card has no chip, the reader is magstripe-only, or the EMV chip read fails and the terminal falls back to swipe. |
| Keyed | No reader is present — software-based entry on a kiosk, in-store web app, or attended manual entry. |
How These Map to Integration Paths
The four entry methods are about how card data is shaped in the API request. The integration paths are about who drives the terminal. The two are orthogonal — pick one of each.
| Integration path | How card-present data reaches /payment |
|---|---|
| Priority Terminal API | You don't call /payment directly. The Terminal API workflow handles EMV / NFC / Swipe via the terminal, then you retrieve the final payment record via the Checkout API. |
| Vendor-Direct | Your application uses the vendor SDK (e.g., PAX VTX-HC, Clover SDK) to capture card data, then submits it to /payment using the field shapes above. |
| Standalone | The terminal processes payments on its own — no /payment call from your side. |
| Keyed CP | Your software captures keyed PAN data and submits it directly to /payment with the keyed field shape. |
Where to Go Next
Submit chip-card encrypted data to /payment.
Submit tap-to-pay data — including mobile wallets — to /payment.
Submit magstripe data to /payment.
Submit manually-keyed CP data with the right posData classification.
Card-present (CP) transactions are payments where the cardholder is physically present at the merchant location. Priority supports four ways to capture and submit card data for CP transactions — chip insert, contactless tap, magstripe swipe, and manual keyed entry. All four hit the same /payment endpoint; what differs is the shape of the card data in the request body.
Who this is for — ISVs submitting captured card data to Priority's Checkout API, regardless of which integration path (Vendor-Direct, custom reader, or keyed entry interface) captured the data.
The Four Entry Methods
Customer inserts a chip card into an EMV-capable reader. The reader returns encrypted TLV data, which you submit as emvData + emvDataKsn.
Customer taps a contactless card or mobile wallet (Apple Pay, Google Pay, Samsung Pay) on an NFC reader. Same field shape as EMV.
Customer swipes a magstripe card through a supported reader. You submit the full magstripe string as cardAccount.magstripe.
Cashier or customer keys card data into software (kiosk, in-store web app, manual entry). You set cardPresent: true and populate posData.
What All Four Have in Common
| Aspect | Detail |
|---|---|
| Endpoint | POST /payment (Checkout API) |
| Authentication | Basic auth — Base64-encoded username:password in the Authorization header |
| Content type | application/json |
| Optional response param | echo=true returns the full payment object without a follow-up GET |
| Merchant identifier | merchantId in the request body |
| Sandbox behavior | Valid-format card numbers approve by default; use documented test cards for declines |
| Settlement | Same merchant account / MID as your card-not-present transactions |
What Differs by Entry Method
| Entry method | How data is captured | Field shape in cardAccount | Reader requirement |
|---|---|---|---|
| EMV Chip | Chip card inserted into EMV reader | emvData (C2 tag) + emvDataKsn (C0 tag) | EMV-capable reader, injected with PPS private key |
| NFC Contactless | Card or wallet tapped on NFC reader | emvData (C2 tag) + emvDataKsn (C0 tag) — same as EMV | NFC-enabled reader, injected with PPS private key |
| Swiped Card | Card swiped through magstripe reader | magstripe — full magstripe string | Supported magstripe reader |
| Card Present (Keyed) | Card data keyed into software | cardPresent: true + posData object (no encrypted card data field) | No reader required — software entry |
EMV and NFC share the same field shape because both produce TLV-encoded EMV-style data. The capture method differs (insert vs. tap); the submission shape is identical.
When to Use Each Method
| Choose... | When... |
|---|---|
| EMV Chip | The card has a chip and the merchant has EMV-capable hardware. Default for in-person CP whenever both conditions are met. |
| NFC Contactless | The customer uses a contactless card or mobile wallet and the terminal has NFC. Fastest customer experience. |
| Swiped Card | The card has no chip, the reader is magstripe-only, or the EMV chip read fails and the terminal falls back to swipe. |
| Keyed | No reader is present — software-based entry on a kiosk, in-store web app, or attended manual entry. |
How These Map to Integration Paths
The four entry methods are about how card data is shaped in the API request. The integration paths are about who drives the terminal. The two are orthogonal — pick one of each.
| Integration path | How card-present data reaches /payment |
|---|---|
| Priority Terminal API | You don't call /payment directly. The Terminal API workflow handles EMV / NFC / Swipe via the terminal, then you retrieve the final payment record via the Checkout API. |
| Vendor-Direct | Your application uses the vendor SDK (e.g., PAX VTX-HC, Clover SDK) to capture card data, then submits it to /payment using the field shapes above. |
| Standalone | The terminal processes payments on its own — no /payment call from your side. |
| Keyed CP | Your software captures keyed PAN data and submits it directly to /payment with the keyed field shape. |
Where to Go Next
Submit chip-card encrypted data to /payment.
Submit tap-to-pay data — including mobile wallets — to /payment.
Submit magstripe data to /payment.
Submit manually-keyed CP data with the right posData classification.