The U.S. payments market is “processor-driven.”
But what does that mean, especially for something as intricate as EMV terminal certification?
In this post, we pull back the curtain on how EMV Level 3 certification typically works in the U.S., highlighting the role of payment processors and the experience for merchants.
In many countries, the path to certifying a payment terminal might be overseen by a central body or dominated by a few large acquiring banks.
In the U.S., however, payment processors (think of companies like First Data/Fiserv, Worldpay, Global Payments, and many others) each have their own certification program.
They act as gatekeepers for any terminal that will connect to their systems. A merchant who wants to set up a new card reader must effectively “ask permission” from their processor via the certification process.
The processor defines the rules of the game, such as which tests to run, which tools to use, and what the merchant needs to submit for approval.
Interestingly, U.S. processors often allow, even expect, merchants to do a lot of the testing themselves (or with their POS vendor) before the processor signs off.
Most processors let their merchants self-test and certify terminals for all stages, from magnetic stripe swipes to EMV chip and even contactless and Card-Not-Present scenarios.
In practice, this means the processor gives the merchant a test plan and says, “Go execute this.”
The merchant might be provided a test card deck (test cards), and typically, they must use an approved test tool, which is often a specific software or device that simulates the network responses.
The processor mandates the tool (merchants don’t get to choose freely), and the merchant or their technical team runs the required test cases on their terminal.
1. Processor issues requirements: When a merchant (or an equipment vendor or integrator working with the merchant) needs to certify, the processor provides a certification guide.
This will include what test tool to use and a list of test cases. The processor’s requirements account for what the major card networks want to see.
Essentially, the processor acts as a translator of network rules into a test checklist. “Merchants are told which test tool to use for their testing and validation,” and the process defined by the processor takes into account the card network needs.
2. Merchant executes tests: Using the mandated tool and their terminal, the merchant runs a predefined set of test cases on the terminal. These include everyday scenarios (a credit sale, a debit sale with cash back, a refund) and edge cases (card declines, offline transaction attempts, incorrect PIN entries, etc.).
It’s a thorough workout for the device. If something as small as printing the receipt incorrectly for a particular card type happens, it might be considered a failure needing correction.
3. Manual log review: Once the tests are done, the merchant collects logs and results and sends them to the processor (or sometimes the processor’s designated lab).
A big sticking point here is that the log analysis is often manual. The merchant’s responsibility might end in running the tests, but on the processor’s side, someone has to review those logs in detail.
They’re checking: did the terminal generate the right authorization request message? Did it handle a chip decline correctly by trying Magstripe as a fallback? Was the correct amount sent to the host?
This analysis is to ensure compliance with card network and processor requirements. It’s meticulous work, traditionally done by certification analysts at the processor or an affiliated lab.
4. Iterations and troubleshooting: Rarely does everything pass on the first go. Maybe the terminal had a bug where it didn’t handle the network’s specific receipt text correctly, or perhaps one of the test cards failed to read due to a hardware quirk.
The processor communicates these issues back to the merchant. Here, the processor-driven nature shows its value and its pain: the processor might help troubleshoot, but often, it’s up to the merchant’s tech team or vendor to fix and then re-run tests.
Processors in the U.S. do provide support, but given the volume of merchants, they often focus on pointing out the issue rather than debugging each merchant’s setup deeply. This means a merchant might be on their own to resolve issues, hire an advisor, or rely on the terminal vendor.
5. Certification granted by processor: Once all test cases pass to the processor’s satisfaction, they (and sometimes the network if network signoff is required) issue a Letter of Approval (LoA) or certification letter.
This officially certifies that the terminal (with its specific configuration and software version) is approved for use on that processor’s network. The merchant can now go live, using that letter as proof if needed.
Throughout this process, the processor is in control. The merchant relies on them for guidance and, ultimately, approval. The U.S. being processor-driven also means each processor’s process might be slightly different.
One may use an online portal for submitting results, another might still use email. One might require a particular brand of test tool, and another might allow a different one. There’s no single universal U.S. certification portal; it’s distributed among many companies.
For merchants dealing with multiple processors (not uncommon if they have different services), this can be a headache. You might have to certify essentially the same terminal numerous times with varying processors in slightly different ways.
From the merchant perspective, a big challenge is that this process isn’t always “merchant-friendly.” They don’t have a say in which tools to use (if the mandated tool is expensive or hard to learn, that’s just too bad). They also must invest a lot of time – running tests and possibly re-running them after fixes.
Much of the validation is out of their hands, done manually by the processor, which takes time and can introduce delays.
For the processor, managing all these moving parts, like many merchants and many tests without a unified system, is tough.
Often, the history of a merchant’s certification attempt lives in email threads and spreadsheets, which isn’t efficient if something similar comes up with another merchant later. It also makes scaling hard: adding more merchants means linearly more emails and files to handle.
The processor-driven approach grew out of necessity. U.S. processors want to ensure nothing connects to their system that could mess up transactions, so they took ownership of certification.
And because the U.S. has so many independent players, a centralized approach didn’t materialize. The result is a bit like a patchwork quilt with lots of individual pieces (processors) doing similar but not identical things.
The good news is that awareness of these inefficiencies is rising. Many processors are now looking into or already implementing more streamlined platforms to handle certification, aiming to give merchants a better experience.
Some collaborate via industry groups to harmonize test requirements where possible. There’s also a trend toward automation (as we’ll discuss in other posts) to alleviate the manual burden.
In short, EMV certification in the U.S. runs on a processor-driven model where merchants self-test under processor guidance.
It has its advantages (processors can tailor and control quality) but also clear drawbacks (duplication, inconsistency, and manual inefficiencies).
Understanding this context is key for anyone working with U.S. payments. It explains why certain things take time and why there’s often a call for patience (and perhaps a bit of prayer) when a new payment device is in the midst of “certifying” before launch.
The model is evolving, but the central role of the processor looks likely to remain, with improvements layered on top to make life easier for all involved.
