Automating NFC testing across payment terminals and phones

Some software tests have to reach into the physical world.

For NFC software, the behaviour we care about involves an interaction between real devices. A phone needs to communicate with a payment terminal, and the software needs to respond correctly when that interaction begins, completes, or is interrupted. Testing the application in isolation only covers part of that behaviour.

This is one of the applied AI problems I am working on: connecting a test agent to a physical fixture so it can exercise NFC interactions remotely, with continuous feedback from the devices involved.

We use this type of setup across a variety of phones and payment terminals. The CI concept is straightforward: when the workflow reaches the hardware test stage, it spawns an AI test agent to operate the test through the fixture and observe what happens. The physical setup supplies a controllable action; device monitoring supplies the evidence.

Making the tap controllable

The fixture holds a phone and a payment terminal back to back, with their rear surfaces facing each other and their displays facing outward. A sliding metal plate sits between them. That plate is attached to a mechanical carriage and guide, allowing it to be inserted and withdrawn while the devices remain mounted.

The plate gives us two useful states:

• Shield inserted: NFC communication is blocked in the fixture, representing the state before the phone and terminal have been tapped together.
• Shield withdrawn: the obstacle is removed, allowing the two NFC interfaces to begin communicating.

This turns the beginning of an NFC interaction into an action the test system can control. Instead of asking someone to bring two devices together for every attempt, we can keep their alignment fixed and change whether they can communicate.

The distinction matters for repeatability. Device position, readiness, and the moment communication becomes possible are separate variables. The jig lets us hold the physical arrangement steady while controlling that last variable.

Each device pairing still needs to be checked: the inserted plate must actually prevent the interaction, and withdrawing it must permit a reliable exchange. Shielding is our way of simulating the transition into contact; reproducing the full motion and changing angles of a person’s hand would be a different test.

Connecting the fixture to CI

The workflow I am building around this follows a small physical test cycle:

1. Prepare the test. Identify the software build, scenario, phone, and terminal. Establish device monitoring before changing the physical state.
2. Start with the shield inserted. Put the devices into the scenario’s starting state while NFC contact is blocked.
3. Arm the interaction. Prepare the phone and terminal for the operation under test, using the controls available for that device pairing.
4. Withdraw the shield. Allow the NFC interfaces to communicate and watch the resulting device behaviour.
5. Evaluate the outcome. Compare the observed events with the scenario’s expected result, preserving the supporting logs.
6. Reset the fixture. Reinsert the shield and return the devices to a known state before another attempt.

The useful boundary is between the agent and the hardware controls. The agent needs operations it can invoke and observations it can interpret. Movement limits, timeouts, and reset behaviour belong in the fixture’s control layer, so the physical action remains predictable.

This also makes the fixture a resource that CI must schedule. A particular phone–terminal pair should belong to one test at a time, with a clear handover after cleanup. Physical devices need that coordination just as shared test environments do.

Observing Android and iOS throughout the test

We continuously monitor the devices rather than relying only on the final screen state.

On Android, ADB provides a connection to the device, with tools such as adb logcat exposing application and system messages. On iOS, monitoring uses the device and application logs available through the development setup. Apple’s Console documentation describes viewing logs from connected devices, including iPhones. ADB is the Android part of this arrangement.

The logs available depend on the device, software, and instrumentation. The test has to use signals that the particular setup actually exposes.

Timing is especially useful here. We want to relate the moment the shield moves to the events that follow: the interface becoming active, the application entering an expected state, a timeout, or an error. A visible response can be useful context, but the application-level outcome needs its own evidence. Establishing an NFC exchange and completing the intended software workflow are separate things to check.

For a remote result to be useful, I want it to answer four questions: which build and device pairing ran, what physical action occurred, what the devices reported, and which expected outcome those observations satisfy.

Where the AI agent helps

Moving a metal plate is a conventional automation task. The AI opportunity is in coordinating the test around that action and interpreting the observations from different devices.

An agent can use the scenario and current device state to work through preparation, invoke the permitted fixture operations, inspect the resulting logs, and assemble a useful explanation when something goes wrong. That is particularly valuable when testing spans different phone models, operating systems, and terminal implementations.

For example, an unsuccessful attempt might involve a device that never became ready, an NFC exchange that began but timed out, or an application that received an event without reaching the expected state. Those possibilities call for different investigation. Relating the logs to the physical test sequence gives the agent something concrete to reason about.

I want the pass or fail decision tied to explicit test expectations. The agent’s interpretation should help explain the evidence and choose bounded next steps. Retries should have limits, and the original failure should remain available for inspection.

Testing across a device matrix

We use the setup with a variety of phones and payment terminals because one successful pairing is only one data point.

The fixture needs to accommodate different device bodies and NFC antenna locations. The software side also varies: Android and iOS provide different monitoring paths, and terminal behaviour can differ between models. A reusable test flow therefore needs device-specific preparation and observation alongside the common shield-and-observe cycle.

Useful scenarios can include the first interaction after readiness, repeated interactions, removal of contact, and recovery after an interrupted exchange. For each scenario, the expected behaviour needs to be defined for the software being tested.

The benefit is the ability to run and investigate these physical interactions remotely after the devices have been mounted and connected. Engineers can work from the test sequence and captured evidence while the hardware remains in the lab.

Applied AI with a physical feedback loop

This work brings together the parts of engineering I enjoy: software, hardware, developer infrastructure, and applied AI.

The fixture makes a physical event controllable. Continuous device monitoring makes its consequences observable. The agent connects those capabilities to a test scenario and helps turn the result into something an engineer can act on.

That is the direction I want to take AI-assisted hardware testing: a CI workflow that can exercise real devices, observe their responses, and return a result grounded in what happened on the bench.