How to Retrieve Logs and Diagnostic Info for Advanced Troubleshooting

Overview

When a merchant's payment device or integration isn't working as expected, the right information helps NMI diagnose the issue quickly. What that information looks like depends on which integration the merchant is using — some produce log files that can be sent directly, others don't produce any logs at all. This article walks partners through confirming which situation applies, and what to send in each case.

What Is Log Retrieval?

Log retrieval is the process of locating and collecting system-generated files that record activity, errors, and configuration details from a device or piece of software. These files help NMI's Support and Integration teams understand what happened leading up to an issue. Not every integration produces these files, so the first step is always confirming which one applies.

Why It Matters for Partners

• Faster resolution: Providing the correct logs upfront reduces back-and-forth and speeds up troubleshooting.
• Merchant guidance: Partners are often the first point of contact when a merchant reports a device issue, so knowing how to request the right files matters.
• Avoiding wasted round trips: Asking a merchant for logs that don't exist for their integration (for example, Cloud API or Direct Connect) just delays things — knowing which path applies from the start avoids this.

Prerequisite: Confirm What the Merchant Is Using

Before requesting anything, identify which integration applies. This determines whether logs can be sent to us.

Note: Still not sure? Look here for NMI's full list of pre-certified payment devices.

If the merchant is using Swipe, Windows/Linux SDK, or Mobile SDK — logs exist and can be sent. Continue to Step 1 below.

If the merchant is using Cloud API, Direct Connect, or Payment API — there is no SDK on their side and no logs to collect. Skip ahead to For Cloud API, Direct Connect, and Payment API at the bottom of this article, and don't attempt to locate log files.

Many of our devices support more than one integration type. If you're not sure how a device you've already purchased is integrated, our support team can help — just provide as much detail as possible (device model, serial number, order/reference number, and how the device is currently being used) so they can confirm it for you.

Step 1: How to Pull Logs

Use the one that applies:

How to Pull Logs for Swipe Software

Swipe Software logs are stored locally on the merchant's machine, in a system folder rather than through a developer tool. There are two types of files to collect: an error log and, if available, server logs.

1. On the merchant's computer, click into the Windows search bar (bottom-left of the screen) and type %localappdata%, then press Enter.
2. A File Explorer window will open. Navigate to the folder Gateway Services.
3. Inside that, open Payment Gateway Swipe.
4. Look for a file named error and collect it — this is the Swipe error log.
5. Next, open the folder Swipe Device (in the same location).
6. Check whether there's a logs folder inside. If there is, open it and collect all files inside — these are the Swipe server logs.

Note: The logs folder does not always exist. If the Swipe server was never initiated on this merchant's machine, there are no server logs to collect — this is expected and not a customer error. If this happens, just send the error log from step 4 and note in your ticket that no server logs folder was present.

What to send: the error file, and (if present) all files from the logs folder inside Swipe Device.

How to Pull Logs for Windows/Linux SDK

Windows/Linux SDK logs are generated by the ChipDNA Server component and stored in the SDK's installation directory on the merchant's machine or server. Two files are needed — a configuration file and a log file — since diagnosing most issues requires both together (the config confirms what device/settings were expected, the log shows what actually happened).

1. On the merchant's device, open File Explorer (Windows) or a terminal (Linux) and navigate to the SDK installation folder.
2. Locate and collect the server configuration file:
   • Windows: C:\Payment Device SDK\ChipDNA Server\chipdna.config.xml
3. Locate and collect the server log file:
   • Windows: C:\Payment Device SDK\ChipDNA Server\logs\ChipDNAServer.log
   • Linux: /opt/chipdna/server/logs/ChipDNAServer.log
4. Send both files together — sending only one will usually mean a follow-up request for the other.

Tip: These paths assume a default installation. If the SDK was installed to a different location, the folder structure will be the same, but the drive letter or root folder may differ — search the machine for chipdna.config.xml if the default path isn't found.

Try to capture a log that covers the entire window during which the issue occurred, ideally including at least one successful transaction for comparison — a log covering only a minute or two around the error often doesn't show enough lead-up to diagnose the cause. These log files also roll over and can be deleted automatically once they reach a certain size, so it's best to collect them as soon as possible after the issue occurs, before they're overwritten.

What to send: chipdna.config.xml and ChipDNAServer.log (or the Linux equivalent), from the same time period as the failure.

How to Pull Logs for Mobile SDK

Where Mobile SDK logs come from depends entirely on how the app was installed on the phone or tablet — this is the first thing to confirm with the merchant or your technical team.

If the app was loaded directly onto the device via Android Studio or Xcode (development or early testing):

The merchant or your technical team can extract the logs directly from the device. Full step-by-step instructions, including screenshots, are in the Mobile SDK Log Extraction guide. In short, this involves connecting the device to Xcode or Android Studio and pulling the log files from the app's data folder.

Note: App Store / Play Store Installs Are Different

If the app was downloaded from the App Store or Play Store (production, including iProcess and other ISV apps), the merchant has no direct access to logs — a setting has to be enabled on NMI's side first before the logs will even be generated.

1. Submit a ticket requesting that a TMS (Terminal Management System) property be set to enable log generation for this device.
2. Include the following in your ticket, since the request cannot be processed without them:
   • The account reference (gateway ID/account name, or TID/terminal group on CardEase)
   • The device serial number
   • The exact date and time range the issue occurred (this is required to generate logs for the correct period)
3. Once the property is set, the merchant will need to perform a TMS update on the device before the logs become available.

Step 2: Send Your Request Like This for a Faster Resolution

Once you've identified the integration type and collected any applicable logs (Step 1), use the steps and template below to submit everything in one go. Including all of this upfront means Support or Integrations can start work immediately, without a follow-up request for missing details.

1. Fill in the ticket description using the copy-and-paste option provided directly below, replacing each bracketed field with the merchant's details. Remove any lines that don't apply. 

I'm reaching out regarding an issue with [EG. Swipe / Windows-Linux SDK / Mobile SDK]. Logs are attached. Here are the details:

Integration solution: [EG. Swipe / Windows-Linux SDK / Mobile SDK]
SDK name and version: [EG. Windows SDK v2.4.1 running on Windows 11]
Third-party software: [EG. POS system, plugin, or middleware, if applicable]
Environment: [EG. Live (Production) / Test (Sandbox)]

Account reference: [EG. Gateway ID/account name, or cardease TID/terminal group]
Transaction ID(s): Failing: [EG. ID] / Working (for comparison): [EG. ID]
Timestamp of issue: [EG. Time, date, and time zone]
Exact error message: [EG. Quote exactly as shown]
Card brand and entry method: [EG. Visa, chip and PIN]

Device make and model: [EG.Ingenico Self 3000]
Serial number: [EG. Serial number]
Connection type: [EG. USB / Bluetooth / network-IP]
Where the device came from: [EG. NMI order number, distributor, or partner]

Number of devices affected: [EG. 1 of 3 devices / all devices]
Number of merchants affected: [EG. 1 / several]
Frequency: [EG. Intermittent / consistent]
Did it ever work, and what changed: [EG. worked until an app/SDK/OS update]

I've attached the following files: [EG. list of log files attached]

2. Attach files, if applicable.

3. Submit a ticket.

For Cloud API, Direct Connect, and Payment API

If the merchant is using Cloud API, Direct Connect, or Payment API, there is no SDK on their side and no logs to collect. Send the following instead:

Cloud API

• Device serial number
• Gateway ID or account name
• Timestamp of the issue, including time zone
• Whether the device is currently showing as registered and connected

Direct Connect

• Account reference (TID on CardEase, gateway ID or account name on ONE)
• Any transaction reference returned to you or the integrator
• Device make, model, and serial number (if a manufacturer device is involved)
• Timestamp, including time zone
• Live or test environment
• Your own request/response trace, if you have one

Payment API

• Gateway ID
• Transaction ID
• Timestamp, including time zone
• Full request payload, if available

Once you have this information, Submit a ticket. 

Key Definitions

• SDK (Software Development Kit): A set of tools used to build or integrate an application, in this case for payment device connectivity.
• TMS (Terminal Management System): A system used to configure and manage settings on deployed devices remotely.
• ChipDNA: The SDK component responsible for communicating with card-reading hardware.
• Swipe Software: NMI's local application used for processing card-present transactions on supported devices.
• Cloud API: A device connection method where the device communicates directly with NMI's platform over the internet, with no SDK installed on the merchant's side.
• Direct Connect: An integration method where requests go straight to NMI's platform without an NMI SDK in the path.
• Payment API: A direct-to-platform integration on ONE, similar to Direct Connect, with no merchant-side SDK.

Need Help?

For additional support, please contact our Support team by Submitting a Ticket.