Before a terminal or a host can accept Visa or Mastercard in production, it has to pass the schemes’ certification testing — EMV Level 3, acquirer-host validation, the Chip Compliance Reporting Tool, MTIP. Teams routinely underestimate this by months. Here is what end-to-end certification really involves.
The schemes’ gate — prove your terminal, host and integration behave correctly before you accept live cards.
Scheme certification is the process by which a card network — Visa, Mastercard and the rest — validates that your terminal, host and integration behave correctly on their rails before you accept live cards. It protects the network’s integrity: a misbehaving acquirer integration creates interoperability and acceptance problems for everyone, so the schemes gate entry with testing.
The headline layer is EMV Level 3 (L3) — testing that a chip terminal, configured for deployment, is correctly integrated into the scheme’s acceptance environment, with connectivity to the acquirer host mirroring production as closely as possible. Below it sit the acquirer-host message and behaviour tests.
Each scheme runs its own machinery. Mastercard’s terminal certification path is the MTIP (Mastercard Terminal Integration Process). Visa’s L3 flow ends with submitting results through the Chip Compliance Reporting Tool (CCRT) on Visa Online. Different tools, same intent: prove it works before it touches a cardholder.
L1/L2 you inherit; L3 and host testing you earn; the schemes do the final sign-off.
The hardware/contact-and-contactless layers (L1) and the kernel application (L2) are certified upstream — usually by the device vendor. You inherit those; you do not redo them.
Your specific integration — terminal configured for your deployment, talking to your acquirer host — tested against the scheme in a near-production environment. This is the work that lands on you.
Message formats, response handling, edge cases, declines, reversals. The host has to do the right thing on every path the scheme cares about.
Visa: results via the CCRT on Visa Online. Mastercard: through MTIP. Sign-off is the scheme’s, not yours — you submit, they approve.
The recurring planning error is treating certification as a short, late-stage formality. It is not. Test-case execution is laborious — many scenarios, each a discrete pass/fail, often run manually unless you have invested in L3 automation. A single defect can mean a fix, a redeploy of the configuration, and a re-run of affected cases.
Then there is scheme turnaround: you submit, and the scheme reviews and approves on their schedule, not yours. Add the dependency chain — your processor, your acquirer, the device vendor’s certified kernel — and a “two-week cert” routinely becomes a multi-month effort once integration realities show up.
Honest planning treats certification as a workstream with its own critical path, started early, with explicit time booked for at least one re-test cycle and for scheme review. Compressing it is how go-live dates slip publicly.
Almost no integration passes every test case on the first run. Build the plan around at least one full re-test cycle — defect, fix, redeploy, re-run, plus scheme review time. A plan that assumes first-pass success is a plan that will slip, and slip visibly because go-live dates get announced.
Decide early whether to invest in L3 test automation. For a one-off integration, manual execution may be tolerable; for a PSP that re-certifies across device models, acquirers and configurations, automation pays for itself by turning a multi-week manual grind into a repeatable run. The cost of getting this wrong is engineering time burned on regression by hand.
And sequence it against the rest: PCI compliance and scheme certification are both preconditions for production. Running them as serial afterthoughts stacks delay on delay. Run them as parallel, early workstreams with named owners.
Visa sign-off is not Mastercard sign-off. Each network certifies separately — budget time for each one you accept.
You control test execution; the scheme controls approval turnaround. Book buffer for a queue you do not own.
A material change to a certified integration can require re-certification of affected cases. “Done once” is not always done forever.