EMV Chip
Submit chip-card encrypted data to Priority's Checkout API — when to use EMV, required equipment, request shape, TLV tag extraction, and best practices.
EMV chip transactions are the most secure card-present method in the Priority gateway. A chip card inserted into an EMV-capable reader returns encrypted TLV data, which your application submits to Priority's Checkout API for authorization. EMV reduces counterfeit fraud, enables liability shift, and typically qualifies for lower interchange than swipe or keyed entry.
Who this is for — ISVs whose deployment captures EMV data from a reader — via a vendor SDK (PAX VTX-HC, Clover), a custom EMV-capable device, or an Ingenico Tetra integration — and submits it to Priority for authorization.
What Defines an EMV Transaction
| Condition | Required |
|---|---|
| Chip card inserted into the reader | Customer presents a chip-equipped card. |
| EMV-capable reader with PPS private key injected | Reader returns encrypted TLV data on chip read. |
Encrypted data submitted via cardAccount.emvData + cardAccount.emvDataKsn | Posted to the /payment endpoint. |
The dynamic cryptogram produced by the chip is what differentiates EMV from a swiped magstripe — every chip read generates unique authentication data the issuer validates against.
When to Use EMV
| Choose EMV when... | Notes |
|---|---|
| The card has a chip AND the merchant has EMV-capable hardware | EMV is the default for in-person CP when both are true. |
| Stronger fraud protection matters to the merchant | Dynamic cryptograms protect against counterfeit fraud. |
| The merchant wants liability-shift protection | Liability shifts to the issuer on EMV-authenticated transactions. |
| Lower processing fees are important | EMV typically qualifies for lower interchange than swipe or keyed. |
For terminals or cards that can't run EMV, see Swiped Card or Card Present (Keyed).
Required Equipment
| Requirement | Where to source |
|---|---|
| EMV-capable card reader or terminal, injected with the appropriate PPS private key | Priority hardware fulfillment — see Supported Terminal Devices |
PCE-enabled merchant account with access to the Checkout API /payment endpoint | Priority Account Management |
How to Submit an EMV Payment
Endpoint
POST /payment (Checkout API)
Authentication
Basic auth — Base64-encoded username:password in the Authorization header.
Authorization: Basic {base64(username:password)}
Content-Type: application/json
Request body
{
"merchantId": "4xxx0",
"tenderType": "Card",
"amount": "0.01",
"cardAccount": {
"emvData": "Xym9TXlYqOusxG1JrdlDqThnzBVZHnTziDjptEdBsv0MasvWV8IOF75Ld0OlntfIxxxxxxxxxxxxxxxx/...",
"emvDataKsn": "8033xxxxxxx000011"
}
}Field reference
| Field | Required | Description |
|---|---|---|
merchantId | ✓ | Your merchant identifier (MID). |
tenderType | ✓ | Always "Card" for card transactions. |
amount | ✓ | Transaction amount as a string. |
cardAccount.emvData | ✓ | Encrypted EMV TLV payload from the reader — extracted from the C2 tag of the TLV. |
cardAccount.emvDataKsn | ✓ | Key serial number associated with the EMV transaction data — extracted from the C0 tag of the TLV. |
Optional: return the full response with echo=true
echo=trueTo receive the full payment object in the response (instead of issuing a follow-up GET), append echo=true as a URL parameter:
POST /payment?echo=true
Successful response
HTTP 201 Created with the payment object's status set to Approved when the transaction is authorized.
Extracting Data from the TLV Payload
EMV readers return data in TLV (Tag-Length-Value) format. From the payload:
| TLV Tag | Goes into... |
|---|---|
| C0 | cardAccount.emvDataKsn |
| C2 | cardAccount.emvData |
[verify — confirm TLV tag conventions are universal across all PPS-injected readers used with Priority]
Where EMV Data Comes From — by Integration Path
The /payment submission is the same regardless of how the data was captured. Only the capture path differs.
| Integration path | How your application gets the EMV TLV data |
|---|---|
| Vendor-Direct: PAX | PAX VTX-HC application returns the encrypted TLV via PAX's SDK. |
| Vendor-Direct: Clover | Clover device application returns the TLV via Clover's SDK. |
| Other certified EMV readers | Read via the manufacturer's SDK and forward the TLV. |
| Priority Terminal API | You don't submit EMV data yourself — the Terminal API workflow handles capture and submission. Retrieve the final payment record via the Checkout API. |
Trade-Offs vs Other Entry Methods
| Aspect | EMV | NFC | Swipe | Keyed |
|---|---|---|---|---|
| Security | Highest | Highest (same crypto as EMV) | Lower | Lowest |
| Liability shift available | Yes | Yes | No | No |
| Interchange rate | Lower | Lower | Higher | Highest |
| Customer experience | Slightly slower (chip read) | Fastest (tap) | Fast | Slowest |
| Hardware required | EMV reader | NFC reader | Magstripe reader | None |
Sandbox Testing
| Behavior | Detail |
|---|---|
| Default outcome | All valid-format card numbers approve in Sandbox. |
| Testing declines, AVS, or CVV failures | Use the documented test cards and scenarios — see Card Test Data. |
| Hardware requirement | A real EMV reader injected with the PPS private key is still required in Sandbox — Sandbox simulates the gateway, not the device. |
Best Practices
| Practice | Why it matters |
|---|---|
| Prefer EMV over swipe when both are available | Stronger security, lower fraud risk, lower interchange. |
| Verify the reader has the PPS private key injected before going live | An un-injected reader will return data that fails decryption. |
Extract TLV tags correctly (C0 → emvDataKsn, C2 → emvData) | Swapped or wrong tags cause authorization failures. |
| Don't truncate or modify the encrypted payload | The encryption breaks if any byte is altered. |
Use echo=true when you need the full payment object immediately | Saves a follow-up GET request. |
Where to Go Next
Back to the entry-method hub — compare EMV against NFC, Swipe, and Keyed.
Same field shape as EMV — for tap-to-pay cards and mobile wallets.
How to set up the PAX or Clover side that captures the EMV data.