The short answer: in a typical Android POS build the device OEM owns hardware conformity documentation and radio/EMC files, the EMVCo Level 2 certificate of compliance (CoC) usually sits with the kernel provider, the PCI MPoC listing sits with whoever submitted the SoftPOS solution, and acquirer approval sits with the acquirer. A logo on a brochure is not custody — ask for the certificate number and the legal entity name printed beside it.
That one sentence decides whether your project ships or stalls in validation. Below is the ownership map, the exact document pack to paste into your RFQ, and the three failure modes that most often turn a funded POS project into an unbudgeted re-test. Treat every row as something to re-confirm with the issuer, because scope, naming and configuration coverage vary project to project and change over time.
Certification ownership matrix: who holds what in an Android POS build
Use this table to separate what your OEM actually controls from what it merely references. The right-hand column matters most in a factory audit: it tells you what you are still missing after the OEM hands over its folder.
| Certificate / approval | Typical holder | What it proves | What it does NOT cover |
|---|---|---|---|
| EMVCo Level 1 | Interface/reader component or device OEM | Physical, electrical and contactless interface behaviour of the tested reader configuration | The payment application logic, the kernel, your brand, or your acquirer’s acceptance |
| EMVCo Level 2 (kernel CoC) | Kernel provider — almost never the device OEM | A specific kernel version passed EMVCo functional evaluation | Your SKU’s model number, your board revision, or antenna tuning |
| PCI PTS (PIN entry device) | Device OEM or secure-module vendor, in that entity’s name | Physical and logical security of a PIN-accepting device (SRED/POI scope) | Software-only acceptance on commercial hardware; acquirer sign-off |
| PCI MPoC listing | Solution submitter — ISV, acquirer or OEM software arm | SoftPOS acceptance, including PIN entry, on commercial off-the-shelf Android hardware | Hardware certifications; per-acquirer scheme letters |
| Scheme letters (Visa, Mastercard, domestic schemes) | Acquirer, processor, or the solution owner in each market | That the solution works within a network’s specific EMV implementation | Other markets; other acceptance models |
| Radio / EMC / safety (FCC, CE, and equivalents) | Device OEM or importer of record | Radio-frequency and product-safety conformity for the tested configuration | Payment security, EMV testing or acquirer approval |
| Key injection / TMS arrangements | Injection facility, TMS operator, or OEM under your brand | Where and under whose custody keys are loaded and managed | Certification status of the device or the app |
A published hardware vendor guidance note makes the boundary explicit: FCC authorisation “addresses radio-frequency compliance and harmful interference” and “does not replace PCI PTS, EMV testing or an acquirer approval” (ZCS, POS Certifications: PCI PTS, EMV, CE and FCC, undated — verify the current text). The same guidance recommends asking the manufacturer to classify any OEM/ODM change as cosmetic, administrative, delta-tested, or requiring a new approval, and recording who pays for testing and who owns the resulting certificate.
That change-classification clause is the single most useful line you can add to a tooling agreement during validation. Sign it before the tooling order, not after the first engineering change.
MPoC or traditional PIN pad? The fork that decides your document set
A terminal with a physical PIN pad routes through PCI PTS plus EMVCo approvals. A tap-to-phone or tablet acceptance model on commercial hardware routes through PCI MPoC — the standard that replaced SPoC and CPoC.
Scope matters here, and it is worth quoting the people who track it. A SoftPOS vendor’s public certification page states that PCI MPoC covers card payments including PIN entry on commercial off-the-shelf devices such as smartphones and tablets, and defines 192 individual security requirements spanning software integrity, cryptographic key management, device attestation and continuous monitoring (Mypinpad certification page, undated — re-confirm against the PCI SSC site). The same page states that existing CPoC and SPoC listings remain valid to their expiry dates, but that new submissions closed on 31 October 2026. Treat that date as a claim to verify at the source before you build a roadmap on it, not as our assertion.
Two mismatches recur in validation:
- Assuming MPoC covers a PIN-pad integration. It does not; a hardened PIN-entry device is a different object with a different certificate holder.
- Assuming a PCI PTS terminal automatically supports a soft-PIN model. It does not; the two paths carry separate evidence, and neither one substitutes for the other at the acquirer.
For a device evidence trail on the hardware side, PCI MPoC certification has been issued at software-vendor level to terminal makers as well as to software houses — for example, Castles Technology announced PCI MPoC Software Vendor certification for its SoftPOS product on 24 May 2024 (Castles Technology announcement). Note what that announcement demonstrates: a vendor-level listing in the vendor’s own name. It is not a transferable asset you can re-badge.
Why EMVCo Level 1 and Level 2 are not device certificates
Level 1 addresses the physical and electrical interface; Level 2 addresses the payment application kernel. So the CoC names a kernel version and a kernel provider — not your model number, and usually not your OEM’s name.
Your verification move in the RFQ is therefore a four-part question: which kernel, which version, whose CoC, and has this OEM’s board revision been tested with that kernel build? A kernel swap or a new kernel release can invalidate the pairing even when both sides individually look current.
Contactless is where this bites hardest. A published EU-facing analysis notes that the EMVCo contactless performance specifications define antenna performance requirements at standard counter read distances of 0–4 cm, and that a terminal with a poorly tuned NFC antenna “may pass basic EMV L1 contactless certification but exhibit read failures in practice — particularly with cards that have weaker antenna coupling”. The recommended request is the vendor’s NFC performance test results against the EMVCo contactless analog test suite, not just the L1 status, because antenna behaviour “cannot be improved through firmware updates” (ZCS, EU Payment Modernisation: Android POS Hardware Requirements 2026, undated).
Apply that to your own market rather than assuming it: ISO 14443 Type A/B behaviour, read distance and card population differ by region, and a passing certificate does not describe field performance with the cards your merchants actually see.
The document pack to request before a tooling order
Paste these seven items into your RFQ. Each one names what it proves and what to cross-check, because a folder of PDFs without cross-checks is a logo wall in a different format.
- Certificate and CoC copies — with certificate number, issuing body, version and expiry date. Proves: something was certified. Cross-check: look the number up on the issuer’s public listing and compare the expiry against your ship date.
- A written ownership statement per certificate — which legal entity holds it, and whether the OEM can sub-licence it, let you reference it, or can only furnish a copy. Cross-check: the named entity should match the contracting party or be explained in writing.
- Software lifecycle and secure-update evidence — because MPoC-style schemes treat ongoing maintenance as part of compliance, not a one-off test. Cross-check: ask who receives and applies security patches, and on what cadence. Our CRA tablet procurement: SBOM and EN 18031 checklist sets out the parallel evidence trail buyers now request for EU-facing devices.
- A test-report index, not the reports — listing which laboratory tested which configuration, and which configurations sit outside scope. Cross-check: confirm the tested configuration matches the SKU and options you are buying.
- Key-injection and TMS arrangements — the named injection facility, and whether keys can be loaded under your brand. Cross-check: the commercial and custody implications of loading under your name.
- Radio, EMC and safety conformity documents for every target market, with the certificate holder named. Cross-check: holder identity and market coverage — the mechanics differ by regime, which our Android tablet certification overview for ANATEL, BIS and SASO illustrates for Brazil, India and the Gulf.
- A delta-test quotation on any customisation — plus written agreement on who pays for it and who owns the resulting documents. Cross-check: get this before you approve the engineering change, not after.
Timeline and cost: what you can and cannot put in a business case
We do not publish certification durations or fees as facts, because they are not ours to publish. The drivers you can actually scope are: the solution’s boundaries, whether an SDK and backend already exist, accredited-lab queue position, the number of device configurations in scope, and how many remediation rounds you plan for.
For a market reference, one certification programme vendor publicly markets an MPoC programme claiming to take solutions from app to “certified-and-shipping in 90 days” with a written deadline guarantee (article dated 7 September 2026 per publisher metadata, unverified — Paying.co). Read that as a vendor programme claim tied to that vendor’s own pipeline and pre-negotiated lab schedules, not as an industry norm and not as a baseline you can copy into a board paper.
Convert it into something defensible: request the accredited laboratory’s own indicative schedule in writing, with your specific device configuration named on it. Then budget one delta-test round explicitly, because re-testing after a mid-project component change is the most common unbudgeted line in these projects.
Three failure modes that stall a POS certification project
1. Certificate custody
The certificate sits with the silicon or kernel provider and cannot be transferred, so your acquirer will not treat a copy as their own approval. Mitigation during validation: identify the acquirer’s own acceptance requirement in writing before the hardware configuration is frozen.
2. Configuration drift
A substitute memory part, a new NFC antenna supplier or a different kernel build moves the device outside the tested configuration. Mitigation: a written configuration-control clause plus the change-classification agreement described above, with the cost owner named per class of change.
3. Funded but unscoped
Testing is commissioned before anyone confirms with the acquirer which scheme letters and which acceptance model are required in each target country. Mitigation: send a scoping email to the acquirer and get a reply before the purchase order, listing each market, each acceptance model and each required letter.
How to verify an OEM’s certification claims in under a week
The sequence is short and mostly administrative:
- Pull the issuer’s public listing for each certificate number and compare the legal entity against the contracting entity.
- Check each expiry date against your planned ship and support window.
- Request the test-report index and confirm the tested configuration matches the SKU and options on your order.
- Ask two reference customers in comparable markets what their acquirer accepted and what it asked for again — and specifically whether any document arrived late.
- Get the acquirer’s acceptance requirement and the lab’s indicative schedule in writing before you commit.
One limit on our own evidence, stated plainly: we have not independently audited any third-party certificate referenced on this page. Every external claim above is attributed to its publisher, dated where the publisher supplied a date, and should be re-confirmed at the source. Certificate scopes and naming conventions change; a page like this cannot substitute for the issuer’s listing.
Frequently asked questions
Does PCI MPoC certification cover the tablet hardware, or only the payment app?
The listing covers the submitted SoftPOS solution and the device conditions defined within it, not your hardware as a product. Hardware conformity, radio and safety files remain separate documents held by the device side.
Can an OEM transfer its PCI PTS certificate to my brand?
Generally no. A PCI PTS approval belongs to the entity named on it. What an OEM can typically do is furnish a copy, state the scope, and support your own submission or your acquirer’s acceptance process. Get the exact permitted use in writing.
If I change the NFC antenna or the memory supplier, does the EMVCo or MPoC work have to be repeated?
It has to be re-assessed, and the outcome depends on the class of change. A radio, antenna, shielding or enclosure change can affect the radio authorisation and the interface test basis; a component change can move the device outside the tested configuration. Require the OEM to classify the change and quote the delta test before approval.
Is a PCI PTS terminal required for SoftPOS, or is MPoC enough for card-present acceptance?
They answer different questions. PCI PTS applies to PIN-entry devices; MPoC applies to acceptance on commercial off-the-shelf hardware. Which one your project needs depends on the acceptance model — and on what your acquirer requires in each market.
How long does MPoC certification actually take for an Android POS OEM project?
There is no responsible single number. It depends on solution scope, existing SDK and backend maturity, lab queue position, the number of device configurations and remediation rounds. Ask the accredited laboratory for an indicative schedule naming your configuration, and treat vendor programme claims as claims about that vendor’s pipeline.
Next step
Request the POS certification document pack — MPoC/PCI-related evidence for the selected model and configuration, an EMVCo CoC ownership statement, and a test-report index — together with a sample unit for evaluation. Review the platform options first, for example the Wintouch Snapdragon 685 11.97-inch business tablet, the Wintouch T616 10.51-inch business tablet or the Wintouch T606 10.36-inch business tablet, then send us the SKU, target markets and acceptance model so the pack we return matches your configuration rather than a generic folder.
To be precise about what that pack contains and what it cannot do: LIONTEK can supply the document pack for the selected model and configuration, with ownership stated certificate by certificate. It cannot convert a third party’s certificate into your acquirer’s approval, and it cannot transfer a certificate held by a silicon vendor, a kernel provider or an acquirer. Verify every certificate number and expiry directly with the issuer.
