NFC Contactless
Submit tap-to-pay encrypted data to Priority's Checkout API — when to use NFC, mobile wallet support, request shape, TLV tag extraction, and best practices.
NFC contactless payments — commonly called "tap to pay" — let customers pay by holding a contactless card or mobile wallet near an NFC-enabled reader. The reader captures the same dynamic cryptogram an EMV chip produces, so NFC and EMV share the same security level and the same submission shape on Priority's Checkout API. The only difference is how the customer physically presents the card.
Who this is for — ISVs whose deployment captures NFC data from a reader — via a vendor SDK, a custom NFC-capable device, or an integrated terminal — and submits it to Priority for authorization.
What Defines an NFC Transaction
| Condition | Required |
|---|---|
| Contactless card or mobile wallet tapped on the reader | Apple Pay, Google Pay, Samsung Pay, or a contactless plastic card. |
| NFC-enabled reader with PPS private key injected | Reader returns encrypted EMV-style TLV data on tap. |
Encrypted data submitted via cardAccount.emvData + cardAccount.emvDataKsn | Same field shape as EMV — posted to /payment. |
Because NFC produces the same dynamic cryptogram and TLV envelope as a chip read, the submission to Priority looks identical to an EMV transaction. Differentiating EMV vs NFC at the API level is not required for authorization — both flow through the same fields.
When to Use NFC
| Choose NFC when... | Notes |
|---|---|
| The customer has a contactless card or mobile wallet AND the merchant has NFC-enabled equipment | Default for customer-facing POS where speed matters. |
| The POS device is customer-facing | NFC is built for the customer to tap directly — not for staff to handle the card. |
| You want a low-friction checkout experience | Fastest of the four entry methods. |
| You want the same security and interchange treatment as EMV | NFC qualifies for the same card-present rates and liability shift as EMV. |
For card-handling scenarios (counters, restaurants, bars where staff process the card), see Swiped Card or EMV Chip.
Required Equipment
| Requirement | Where to source |
|---|---|
| NFC-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 NFC Payment
The submission shape is identical to EMV. The reader supplies the encrypted TLV; you forward it to /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 NFC/EMV TLV payload from the reader — extracted from the C2 tag of the TLV. |
cardAccount.emvDataKsn | ✓ | Key serial number associated with the NFC transaction data — extracted from the C0 tag of the TLV. |
Optional: return the full response with echo=true
echo=trueTo receive the complete 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
NFC readers return data in TLV (Tag-Length-Value) format — the same format as EMV. 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]
Mobile Wallets
NFC supports mobile wallets out of the box — Apple Pay, Google Pay, Samsung Pay, and any wallet implementing standard contactless EMV protocols. From the API's perspective there is no distinction between a contactless plastic card and a tokenized mobile wallet — the reader returns TLV data in both cases, and you submit it the same way.
Where NFC Data Comes From — by Integration Path
| Integration path | How your application gets the NFC 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 NFC readers | Read via the manufacturer's SDK and forward the TLV. |
| Priority Terminal API | You don't submit NFC 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 |
| Mobile wallet support | No | Yes | No | No |
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 NFC reader injected with the PPS private key is still required in Sandbox — Sandbox simulates the gateway, not the device. |
| Testing wallets | Any NFC-enabled mobile wallet on a test card or contactless card works for sandbox capture. |
Best Practices
| Practice | Why it matters |
|---|---|
| Use customer-facing reader placement | NFC is built for the customer to tap directly — placement matters for the speed advantage. |
| 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. |
| Don't differentiate NFC from EMV at the API level | They share the same submission shape — your routing logic should treat them as one. |
Where to Go Next
Back to the entry-method hub — compare NFC against EMV, Swipe, and Keyed.
Same field shape as NFC — for chip-card-insert transactions.
How to set up the PAX or Clover side that captures the NFC data.