0
What a failing JCB ATM certification taught us about what quality engineering actually means in payments
There is a version of quality engineering that is process-shaped. Stand up the test environment. Write the test cases. Run them. Log the failures. Investigate. Repeat. It is methodical; it is documentable; in payments, it is not enough.
Here is a scenario that illustrates why.
A payment processor in the LATAM region was using Payhuddle’s Tecto EMV L3 tool to certify their ATM terminals for the JCB network. The tests were failing. The customer assumed the tool was the problem.
It was not.
Payhuddle’s team pulled every available log: card logs, terminal logs, and terminal reader logs. They traced the transaction flow at each layer rather than accepting the test failure at face value. What they found was not a defect in Tecto. It was a defect in the terminal’s behavior.
The terminal was transmitting two to three extra lines of command data that the EMV specification does not call for. On its own, that might seem like a minor deviation. But EMV cards have a fixed, finite transaction log memory. Every command written to that log consumes a portion of it. The terminal’s extra commands were exhausting the card’s log memory before the certification test sequence could complete. The tests failed not because the tool was wrong, but because the terminal was writing data it had no business writing.
Once the root cause was documented, Payhuddle engaged the terminal vendor with the full analysis: the specific commands, the EMV clause they violated, and the precise mechanism of failure. JCB was brought in to confirm the findings. The resolution was a targeted update to Tecto to read the JCB card log correctly in the context of this terminal’s non-standard behavior. After the update, the certification tests ran without issue. All five terminals were certified.
That outcome was only possible because the team did not stop at the test result. They understood the full chain: what the card was doing, what the terminal was doing, what the network expected, and where those three things diverged.
It would be easy to frame this as a good example of technical problem-solving. It is that. But it is also something more specific: what quality engineering looks like when built around domain knowledge rather than process compliance.
In payments, the chain from a failed test to its root cause rarely stays within a single system. A terminal issue can be traced back to a host configuration. A certification failure can be traced back to a requirements gap. A card log memory error can be traced back to non-standard terminal behavior that nobody flagged during development because no one on the team had seen that combination of terminal type, network, and card profile before.
Process-shaped quality engineering captures what falls within the process. Domain-shaped quality engineering catches the things that fall between the systems.
What shift-left actually means in the certification context
The phrase “shift-left testing” has become so common in engineering that it has almost lost meaning. In most contexts, it means: write tests earlier, involve QA before code is written, don’t find bugs at the end.
In a certification context, it means something more specific and more demanding.
When Payhuddle’s testing team is involved in a certification engagement, the work that happens before the network window opens is where most of the value is created. That means:
None of this is possible without engineers who understand both the testing process and the payments domain deeply enough to know what questions to ask at the planning stage.
In the ATM certification engagement, the root cause, a terminal transmitting non-standard commands that exhausted the EMV card log memory, was not something that a generic test framework would have surfaced. It required someone who understood EMV card memory architecture, knew what the JCB network expected at each transaction stage, and was willing to consult the logs rather than accept the failure message as the full story.
Every certification engagement Payhuddle runs carries the same expectation: if something fails, the team’s job is not to report the failure. It is to understand it well enough that the fix is precise, the resolution is durable, and the customer does not have to come back for the same problem in a different form.
That standard is harder to maintain than a process checklist. It requires engineers who can move across layers, from card to terminal to host to network, and who carry enough accumulated experience to recognize, when something unexpected appears in a log, whether it is noise or signal.
In payments, quality engineering is not a function that sits at the end of delivery and checks whether things work. It is the capability that understands the full chain well enough to find the real problem, wherever in the chain it lives.
