On the surface, EMV Level 3 certification sounds straightforward.
Run tests, fix issues, and get approved.
But anyone who’s been in the trenches of certification knows there’s a lot of waste and inefficiency lurking beneath that simple summary.
In this post, we will look at the less-obvious inefficiencies in the traditional certification process for payment terminals and why they’re holding back the industry.
One of the biggest inefficiencies is the lack of a centralized tracking system. Many certification teams of processors still rely on a combination of emails, spreadsheets, and shared folders to keep track of each project.
Imagine a processor that has 5 terminal models being certified simultaneously across perhaps three different regions or business units. If each project’s details are buried in someone’s inbox or an Excel file, management has no easy way to see the overall status. Things fall through the cracks.
In fact, it’s noted that there’s often no unified platform to monitor certification activities across regions and divisions, which means duplicated efforts and inconsistent information. One team might solve a problem in one certification, and another team might encounter the same problem later without knowing a solution already existed because the knowledge wasn’t shared globally.
The certification workflow involves multiple phases like onboarding a merchant or device, actual testing, analysis of results, tracking issues, retesting, reporting, etc.
In a fully manual setup, these steps are handled by different people using different tools that don’t talk to each other. Nothing is automated end-to-end.
For example, a merchant might fill out a form to start the process (one system), tests are run on a separate test tool (another system), results are emailed (outlook), and an analyst reviews them using a PDF of network specs (offline document), and then writes up a report in Word. None of these steps integrate.
It’s noted that the industry lacks a platform that automates the entire testing and certification flow, from onboarding to testing, analysis, tracking, reporting, and audit trail.
The entire process is low, and it requires constant human coordination to move from one step to the next.
Perhaps the most time-consuming inefficiency is how test results are checked. Today, in many cases, a human being opens up log files or tool outputs and painstakingly compares them against expected results. This is like proofreading a novel by hand, which is error-prone and exhausting.
There is a lack of automation in data analysis and validation, making it a manual process. Not only does this consume a lot of hours, but it also means if that one key expert is out sick or on vacation, everything waits.
It’s an archaic approach in an era where software can parse data far faster.
Here’s a scenario that happens more often than you’d think.
Merchant A and Merchant B are both certifying the same terminal model with the same processor, maybe just at different times.
Merchant A hits an issue, and the processor’s team finds a workaround or grants a waiver. A few months later, Merchant B hits the exact same issue.
If knowledge isn’t shared well, Merchant B’s case might go through the same troubleshooting motions, wasting time.
History and decisions are often scattered across emails and calls with no central knowledge base, meaning lessons learned aren’t easily accessible. This is hugely inefficient, which is equivalent to resetting to zero for each project.
Certifications often involve multiple parties, such as the merchant, the processor’s cert team, sometimes the terminal vendor or an integrator, and possibly network representatives. Coordinating all these via email or phone is clumsy.
A common inefficiency is a delay in communication. For e.g., the processor finds an issue and emails the merchant; the merchant’s team lead is out that day, so they don’t see it for 24-48 hours; then they fix and reply, but now the processor’s analyst is in back-to-back meetings, so another day passes. Multiply these delays by a few cycles, and you’ll add weeks.
Without a real-time collaborative platform, reaching individuals or groups of merchants quickly is hard, especially at scale. And if a merchant has a question, figuring out who to ask on the processor’s side can be confusing. Maybe they email one person, who has to forward it to the right expert.
It’s a lot of waiting and misrouting.
Even as the chip takes over, many certifications still require demonstrating that the terminal can handle magnetic stripe (MSR) transactions as a fallback.
Shockingly, MSR testing is often done manually, which means someone actually swipes cards and checks that data rather than using an automated script.
It’s a bit ironic that we have advanced simulators for chip tests, but then we fall back to manual for swipe. This tends to be because the focus has been on automating EMV scenarios; the old swipe tests were left in an antiquated state.
But it is an inefficiency where humans do what machines can do easily.
After tests are done, compiling the results into a formal report or Letter of Approval (LoA) can take days of manual work, formatting documents, and double-checking entries.
This often happens at the very end, when everyone is anxious to launch, making the wait even more painful. It’s a purely administrative task that is ripe for speeding up, yet in many organizations, it remains manual.
In certification, a “waiver” is an agreed exception. Maybe a certain EMV test can’t be passed due to a unique situation, and the network/processor grants a pass on it.
Keeping track of waivers is crucial (so you remember that Terminal X is approved even though it didn’t do Y, and you know why). However, no centralized system for managing waivers means these often live in emails or one-off documents.
Later on, if someone asks, “Why was this terminal certified without feature Y?” it becomes a treasure hunt to prove the waiver existed. The inefficiency here is both in answering such questions and in ensuring consistency (you might grant a waiver to one merchant, and then a year later, another merchant has the same issue, but no one realizes a precedent was set).
All these inefficiencies add up to longer timelines and higher costs.
They’re “hidden” in the sense that no one line item on a project plan says “3 days lost to email delays” or “1 week spent re-reading logs,” but they’re real and pervasive.
For payment processors, addressing these hidden inefficiencies is now a priority. It’s not just about complaining, but it’s about recognizing that as the volume of certifications grows (with new devices, updates, and fintech innovations), the old way of working simply won’t scale.
The encouraging news is that the industry is acknowledging these pain points. Efforts to introduce automation and centralized platforms directly target these inefficiencies.
For example, a single platform can provide unified tracking, automated analysis, knowledge base features, faster reporting, waiver management, and so on.
But even before such tools are fully adopted, just being aware of these bottlenecks can help teams streamline what they can, like improving internal knowledge sharing or templatizing reports to cut down preparation time.
Fixing these hidden inefficiencies is about making everyone’s life easier. Merchants get certified faster, processors use their talent for higher-level work instead of grunt work, and the payment networks see fewer errors in the field.
It’s a classic case of “work smarter, not harder.”
