NFC Contactless

NFC (Near Field Communication) contactless payments — often called “tap to pay” — let customers pay by holding a contactless card or mobile wallet near an NFC-enabled reader. The reader securely captures the payment data and sends EMV-style encrypted data to the PCE payment API.

Prerequisites and limitations

• Prerequisites: An NFC-capable terminal or reader injected with the correct keys, a configured merchant account, and access to the PCE /payment API.
• Limitations: NFC is designed for card-present, customer-facing POS environments. It’s less common where cards are handled behind the counter (for example, some restaurants, bars, and similar venues).

When to Use NFC Contactless Payments

NFC transactions are a good fit when:

• The customer has a contactless plastic card and the merchant has NFC-enabled equipment.
• The customer wants to pay with a mobile wallet such as Apple Pay, Google Pay, Samsung Pay, or similar, and the merchant has NFC-enabled equipment.
• The POS device is customer facing, and you want a quick, low-friction tap experience instead of passing a card back and forth.

NFC is commonly used in retail and self-checkout scenarios where the card or phone is tapped directly on the terminal. It’s less common where the card is taken away from the customer to be processed behind a counter.

Required Equipment

You’ll need:

• An NFC-enabled card reader or terminal injected with the PPS private key.
• A PCE-enabled merchant account.

Things to Keep in Mind

• Same payment data structure as EMV: The API fields and encrypted payload are the same as EMV chip transactions (emvData and emvDataKsn). The difference is how the card information is captured — a tap rather than inserting the card.
• Customer experience: NFC is fast and familiar for customers, especially those using mobile wallets.
• Security: Like EMV, NFC contactless uses dynamic cryptograms and strong encryption, making it more secure than keyed or swiped transactions.
• Fees: Because these are card-present, secure transactions, NFC payments often qualify for lower processing fees than keyed or swiped transactions, similar to EMV.

Make an NFC Payment Request

NFC transactions send EMV-style data from the reader. You submit this encrypted data in the cardAccount.emvData and cardAccount.emvDataKsn fields on the /payment endpoint.

Endpoint

Steps

1. Set up the HTTP request

   • Use the POST method.
   • Call the /payment endpoint in the desired environment (sandbox or production).

2. Add authentication and headers

   • Send your username and password in the Authorization header using Basic auth.

     • Encode username:password as Base-64 and prefix with Basic .

   • Set the Content-Type header to application/json.

3. Provide EMV-style data from the NFC reader

   Build a JSON payload similar to the following:

   JSON

   {
     "merchantId": "4xxx0",
     "tenderType": "Card",
     "amount": "0.01",
     "cardAccount": {
       "emvData": "Xym9TXlYqOusxG1JrdlDqThnzBVZHnTziDjptEdBsv0MasvWV8IOF75Ld0OlntfIxxxxxxxxxxxxxxxx/...",
       "emvDataKsn": "8033xxxxxxx000011"
     }
   }

   • merchantId: Your merchant identifier.
   • tenderType: Set to "Card".
   • amount: The transaction amount.
   • cardAccount.emvData: Encrypted NFC/EMV data from the reader (TLV-based payload; example truncated).
   • cardAccount.emvDataKsn: The key serial number for the NFC transaction.

4. (Optional) Return the full response with echo

   • Add echo=true as a URL parameter to return the full payment object in the response: POST /payment?echo=true
   • This avoids a separate GET call to retrieve payment details.

5. Collect NFC data from the reader

   • You can use any supported mobile wallet or NFC-enabled card for testing.

   • You must use an NFC-enabled reader injected with the PPS private key.

   • The reader returns encrypted TLV data. From that payload:

     • Use the C0 tag for the emvDataKsn field.
     • Use the C2 tag for the emvData field.

6. Verify the response

   • A successful NFC payment returns HTTP 201 Created.
   • The payment object’s status field should be Approved when the transaction has been approved.

Testing Behavior in Sandbox

• The Sandbox environment uses a simulator, not a live gateway.
• Sandbox will approve all cards that use a valid credit card format by default.
• To simulate declines and other error scenarios, use the documented testing cards and test values (for example, specific card numbers or amounts).