Developers build. Project managers plan. Test specialists run the tools.
EMV testing means running brand test cases with professional test tools and keeping the evidence. It is a different skill from writing payment software and from managing a project. We run it for you, so your developers stay on the product and your schedule stays visible.
> A0 00 00 00 03 SELECT > GET PROCESSING OPTIONS > A0 00 00 00 04 0x9000 > AAC · EMV L3 > 9F10 9F36 9F27 9F33 03 TVR > GENERATE AC ✓ APPLICATION CRYPTOGRAM ACCEPTED
A certification project goes wrong when one person is asked to do all three jobs. Each job needs different tools and different habits. We supply the third role, and we work alongside the first two.
Build and fix the payment application.
Code, kernels, SDKs, terminal behavior, processor messaging.
Learning a test tool and a brand's rules while also shipping features.
Manage the tasks, the people and the dates.
Scope, dependencies, vendors, processor and brand scheduling, communication.
Guessing what a failed test case means, or chasing logs.
Run the test tools and the brand test cases.
Test tools, test selection, simulators, logs, pass criteria, evidence.
Writing the application or owning the schedule.
EMV testing is the execution of test cases that show a terminal and its payment application work end to end with a processor and the card brands. It comes after the hardware and kernel are approved, and it produces the evidence a certification depends on.
EMVCo does not run Level 3 testing. Each payment system sets its own Level 3 test cases and policies. EMVCo defines the standard test tool components and qualifies test tools. Testing is also not the same as approval: the tools produce results and logs, and the processor and the brands decide whether to approve. Read more in the EMV Level 3 certification process guide.
Commercial tools from specialist vendors run the brand test cases for many schemes. The brands and some processors also provide their own tools, simulators and reporting systems. A tester knows which one a processor will accept. You do not need to buy, rent or learn any of it: we own and operate the tools.
How tools are approved: EMVCo qualifies Level 3 test tools and lists the qualified ones. Brands also qualify or confirm tools for their own programs, and a processor may require one over another. We confirm which tool and version your processor and brands accept during scoping.
Each brand sets its own test cases, tools and approval path, and these change over time. This table shows how the main US brand programs have been structured, so you can see why a single tester needs to know several.
Within the United States and most markets, these brands and programs are available. Outside the US the card brands, their test programs and the regional schemes differ by country, so we confirm the current requirements with each brand and your processor for your project.
See the Canada, Mexico and Puerto Rico pages for regional detail.
The loop is steps 3 to 6. Most of the calendar is spent there, and it is where a fast triage helps most. Each step has one owner.
Confirm the processor, brands, terminal, kernel and entry modes. Agree scope and dates. Output: test plan and schedule.
Load the build, check configuration against the approved kernel, set up tools and cards. Output: a terminal ready for testing.
Run the brand test cases with the tools, record logs and results. Output: results and logs per case.
Decide whether each failure is the application, the configuration, the host or the tool. Output: findings with causes.
Change the application or configuration. Output: a new build.
Rerun the affected cases, and regression where needed. Go back to Execute until all pass.
Assemble logs and evidence in the format the processor and brands expect.
Send the package, answer reviewer questions, track approval.
In a managed certification this is how we split the work. In a full build we cover the developer column as well.
Each brand has its own tools, test selection and pass criteria, and they change. Someone who runs them every week spots problems that a developer running them once will miss.
Incorrect terminal configuration and inadequate integration testing are common causes of acceptance problems, even when the card and the terminal are both approved. A tester finds these quickly.
Logs must match the simulator logs, the chip data sent to the host must not be altered, and results must map to cases. A tester keeps this discipline from the first run.
Every hour spent learning a tool or reading a brand document is an hour not spent on the product.
When testing sits inside one developer's head, the schedule depends on that person. With a dedicated tester, progress is reported by case, which a manager can track.
A tester knows what a kernel, application, route or configuration change forces you to rerun, and what only needs regression. That keeps change from turning into surprise delay.
We need from you: the processor and host, the terminal, the kernel and firmware versions, the build, and access to the processor's specifications and test credentials. Work is quoted against a fixed-scope Statement of Work with milestone billing. Timelines depend on your scope and on the processor's and brands' own scheduling.
The full overview: engagement options, scope, process and examples.
GUIDE · PROCESSThe stages, owners and handoffs in more depth.
GUIDE · BUDGET AND SCHEDULEUnderstand EMV certification cost and timeline factors.
BLOG · ENGINEERING QAEngineering QA that sits alongside brand testing.
The more we know up front, the more precisely we can scope it. Please include:
Tell us about your project — we route you to the right specialist.