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

ConditionRequired
Chip card inserted into the readerCustomer presents a chip-equipped card.
EMV-capable reader with PPS private key injectedReader returns encrypted TLV data on chip read.
Encrypted data submitted via cardAccount.emvData + cardAccount.emvDataKsnPosted 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 hardwareEMV is the default for in-person CP when both are true.
Stronger fraud protection matters to the merchantDynamic cryptograms protect against counterfeit fraud.
The merchant wants liability-shift protectionLiability shifts to the issuer on EMV-authenticated transactions.
Lower processing fees are importantEMV 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

RequirementWhere to source
EMV-capable card reader or terminal, injected with the appropriate PPS private keyPriority hardware fulfillment — see Supported Terminal Devices
PCE-enabled merchant account with access to the Checkout API /payment endpointPriority 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

FieldRequiredDescription
merchantIdYour merchant identifier (MID).
tenderTypeAlways "Card" for card transactions.
amountTransaction amount as a string.
cardAccount.emvDataEncrypted EMV TLV payload from the reader — extracted from the C2 tag of the TLV.
cardAccount.emvDataKsnKey serial number associated with the EMV transaction data — extracted from the C0 tag of the TLV.

Optional: return the full response with echo=true

To 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 TagGoes into...
C0cardAccount.emvDataKsn
C2cardAccount.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 pathHow your application gets the EMV TLV data
Vendor-Direct: PAXPAX VTX-HC application returns the encrypted TLV via PAX's SDK.
Vendor-Direct: CloverClover device application returns the TLV via Clover's SDK.
Other certified EMV readersRead via the manufacturer's SDK and forward the TLV.
Priority Terminal APIYou 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

AspectEMVNFCSwipeKeyed
SecurityHighestHighest (same crypto as EMV)LowerLowest
Liability shift availableYesYesNoNo
Interchange rateLowerLowerHigherHighest
Customer experienceSlightly slower (chip read)Fastest (tap)FastSlowest
Hardware requiredEMV readerNFC readerMagstripe readerNone

Sandbox Testing

BehaviorDetail
Default outcomeAll valid-format card numbers approve in Sandbox.
Testing declines, AVS, or CVV failuresUse the documented test cards and scenarios — see Card Test Data.
Hardware requirementA real EMV reader injected with the PPS private key is still required in Sandbox — Sandbox simulates the gateway, not the device.

Best Practices

PracticeWhy it matters
Prefer EMV over swipe when both are availableStronger security, lower fraud risk, lower interchange.
Verify the reader has the PPS private key injected before going liveAn 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 payloadThe encryption breaks if any byte is altered.
Use echo=true when you need the full payment object immediatelySaves a follow-up GET request.

Where to Go Next


.readme-logo { display: none !important; }