Why Do EMV L3 Certification Projects Get Delayed?
Most delays on an L3 campaign have nothing to do with the EMV testing itself. They come from queue position at a shared lab, slow hand-offs between separate testing and development teams, and — the one thing no vendor can fix — how long a scheme takes to review a submission.
The Four Real Causes of Delay
Lab Queue Position
When certification runs through a shared or rented lab, your campaign is scheduled around every other client's campaign on that lab's calendar. Usually the single largest source of delay — and it has nothing to do with how ready your terminal is.
Slow Fix Hand-Offs
A defect found during testing has to go back to whoever wrote the application. When the test house and the development team are different vendors, that's a ticket, a queue on their side, and a wait for the next available slot to retest.
Platform Surprises
An EMV kernel version that doesn't match what was expected, undocumented terminal behaviour, or a fleet running mixed firmware. These show up mid-campaign and cost discovery time nobody scoped for.
Scheme Review Time
After submission, the card scheme reviews the evidence. Entirely outside any vendor's control, and it varies by scheme and by their own workload.
Two of These Are Structural — and Removable
Causes 1 and 2 are eliminated by running certification in-house: there's no shared calendar to queue behind, and when the same team tests and builds the application, a defect gets fixed the same day instead of routed into someone else's backlog. That's the direct mechanism behind our own timelines — see how long certification actually takes and how in-house tooling compares to a rented lab.
Cause 3 is mitigated by platform experience — a kernel we've already certified holds fewer surprises than one we haven't. Cause 4 isn't fixable by anyone. The honest move is to plan for it rather than promise around it.