PCI MPoC (Mobile Payments on COTS) é o padrão de segurança do PCI SSC que permite aceitar pagamentos com cartão — por aproximação e com digitação de PIN — diretamente em um smartphone ou tablet comum, sem hardware dedicado. Ele define objetivos de segurança para o software, a atestação e o monitoramento contínuo que tornam esse modelo seguro.
Na prática, o MPoC é o que sustenta as soluções de "Tap to Pay" e SoftPOS: um aplicativo instalado em um dispositivo de prateleira (COTS, commercial off-the-shelf) passa a ler cartões pela antena NFC e a capturar o PIN na própria tela. Como esse dispositivo não foi projetado para ser um terminal seguro, o padrão desloca a proteção do hardware para uma combinação de software resistente a ataques, criptografia dos dados da conta e uma infraestrutura de atestação e monitoramento que verifica, transação a transação, se o ambiente é confiável.
O que significa a sigla MPoC?
MPoC significa Mobile Payments on COTS — pagamentos móveis em dispositivos de prateleira. "COTS" é qualquer aparelho de consumo não modificado: um celular Android, um iPhone, um tablet. O ponto central do padrão é justamente esse: aceitar dados de cartão em um equipamento que não passou por avaliação física de segurança, sem leitor externo e, quando necessário, capturando o PIN na tela de toque.
Publicado pelo PCI Security Standards Council em 2022, o MPoC é um padrão baseado em objetivos de segurança, e não em uma lista fechada de controles obrigatórios. Em vez de mandar "faça exatamente X", ele define o resultado que precisa ser alcançado e deixa ao fornecedor demonstrar, com evidência, que a implementação atinge aquele objetivo. Isso dá flexibilidade para diferentes arquiteturas — mas exige avaliação técnica competente para provar equivalência.
Qual a diferença entre MPoC, SPoC e CPoC?
MPoC unifica e amplia dois padrões anteriores: o SPoC, focado em digitação de PIN, e o CPoC, focado em leitura por aproximação. Antes do MPoC, um provedor que quisesse aceitar contactless e PIN no mesmo celular precisava conciliar dois padrões separados. O MPoC junta os dois cenários em um único arcabouço modular e ainda permite transações de maior valor com verificação de PIN na tela.
| Aspecto | SPoC | CPoC | MPoC |
|---|---|---|---|
| Sigla | Software-based PIN Entry on COTS | Contactless Payments on COTS | Mobile Payments on COTS |
| Entrada de PIN no celular | Sim, na tela | Não | Sim, na tela (opcional por módulo) |
| Leitura por aproximação (NFC) | Não (exige leitor SCRP externo) | Sim, na antena do COTS | Sim, na antena do COTS |
| Leitor de cartão externo | Obrigatório (SCRP) | Não | Não |
| Verificação do portador (CVM) | PIN | Sem CVM / limitada | PIN na tela do COTS (módulo PIN Entry on COTS); demais CVMs conforme o cartão/bandeira |
| Estrutura | Controles prescritivos | Controles prescritivos | Objetivos de segurança, modular |
| Situação | Padrão anterior, ainda vigente | Padrão anterior, ainda vigente | Padrão atual e unificado |
A leitura da tabela é direta: SPoC resolvia o PIN mas dependia de um leitor de cartão seguro acoplado; CPoC resolvia a aproximação mas sem PIN, o que limitava o valor das transações; o MPoC entrega os dois no mesmo aplicativo e substitui a lógica de "controle prescritivo" por uma de objetivos, permitindo arquiteturas mais variadas desde que a segurança seja comprovada.
Como o MPoC protege os dados sem hardware seguro?
O padrão protege a transação distribuindo a segurança em três frentes que trabalham juntas, já que nenhuma delas é confiável isoladamente em um dispositivo de consumo. A confiança não vem do aparelho: vem da capacidade do software de se proteger, criptografar os dados e ser verificado remotamente a cada uso.
As três frentes são:
- Software resistente a ataques. O SDK e o aplicativo de pagamento são construídos com proteções contra engenharia reversa, adulteração, hooking e depuração. O padrão trata o próprio ambiente de execução como hostil.
- Proteção dos dados da conta. O número do cartão e o PIN são cifrados o mais próximo possível do ponto de captura e nunca ficam expostos em claro na memória do dispositivo ou em trânsito.
- Atestação e monitoramento contínuos. Um backend verifica, transação a transação, a integridade do aplicativo e do dispositivo — se há sinais de root, emulação, adulteração ou ambiente comprometido — e é capaz de bloquear ou reagir em tempo real.
O MPoC organiza esses requisitos em módulos. Há módulos para o núcleo da solução (CORE), para a proteção do SDK, para a atestação e o monitoramento, para a entrada e o processamento seguros dos dados da conta, para a entrada de PIN no COTS, para transações offline e para a gestão e integração do software. Essa modularidade é o que permite avaliar apenas as partes relevantes para cada tipo de produto.
Como funciona a avaliação de conformidade?
A conformidade com o MPoC é atestada por um laboratório reconhecido pelo PCI SSC, e não por autoavaliação. O fornecedor não "se declara" conforme: submete a solução ou o componente a um avaliador credenciado, que testa contra os objetivos de segurança e emite um relatório aceito pelo Council.
O fluxo típico envolve as seguintes etapas:
- Escopo e classificação. Define-se o que está sendo avaliado — uma solução MPoC completa ou um componente/SDK — e quais módulos se aplicam àquela arquitetura.
- Preparação e evidências. O fornecedor reúne a documentação de projeto, a análise de ameaças, as decisões de arquitetura e as evidências de que cada objetivo de segurança é atendido.
- Avaliação laboratorial. O laboratório reconhecido executa a análise de segurança: revisão de projeto, testes do software (incluindo resistência a ataques), validação da criptografia e da lógica de atestação e monitoramento.
- Listagem. Solução ou componente aprovado passa a constar na lista pública de produtos validados do PCI SSC, o que dá visibilidade a adquirentes e bandeiras.
- Manutenção contínua. Diferente de uma auditoria pontual, o MPoC pressupõe atestação e monitoramento em operação e revalidação periódica; mudanças relevantes no software exigem reavaliação.
Um ponto importante: como o padrão é baseado em objetivos, boa parte do esforço está em demonstrar equivalência — provar, com evidência técnica, que uma escolha de arquitetura atinge o objetivo de segurança pretendido. É aqui que a qualidade do trabalho de segurança antes da submissão determina o tempo e o custo da avaliação.
Quem precisa de PCI MPoC no Brasil?
Precisa de MPoC quem desenvolve ou fornece software que transforma um dispositivo de consumo em instrumento de aceitação de cartão. No ecossistema brasileiro de pagamentos, isso alcança um grupo crescente de empresas à medida que o "Tap to Pay" se populariza:
- Adquirentes e subadquirentes que oferecem aceitação por aproximação no próprio celular do lojista, sem maquininha.
- Fintechs e facilitadores de pagamento que embarcam a função de recebimento dentro do próprio aplicativo.
- ISVs e desenvolvedores de SoftPOS que constroem o SDK ou o app de pagamento vendido a terceiros.
- Marketplaces e plataformas que querem que o vendedor receba presencialmente usando apenas o smartphone.
No Brasil, a exigência do MPoC chega por duas vias que se somam. A primeira é contratual e de bandeira: Visa, Mastercard e demais bandeiras exigem validação PCI para habilitar soluções de aceitação no celular, e essa exigência desce pela cadeia até o desenvolvedor. A segunda é regulatória: instituições de pagamento e arranjos de pagamento operam sob a supervisão do Banco Central, e as resoluções do BACEN/CMN sobre segurança cibernética — incluindo a 4.893 — impõem requisitos de gestão de risco e de segurança que tornam a adoção de padrões reconhecidos como o MPoC parte natural da governança. Quem processa dados de portador ainda precisa observar a LGPD no tratamento dessas informações.
Vale a distinção: o MPoC trata da solução de aceitação no COTS. Ele não substitui a conformidade com o PCI DSS do ambiente que processa, armazena ou transmite os dados de cartão no backend — os dois convivem. Uma operação madura combina a solução MPoC validada na ponta com um ambiente PCI DSS conforme na retaguarda.
Como a Berghem executa
A Berghem apoia fornecedores de SoftPOS e instituições de pagamento em todas as fases que antecedem e sustentam a validação MPoC: modelagem de ameaças do aplicativo e do SDK, análise de resistência a ataques (engenharia reversa, adulteração, hooking e root/jailbreak detection), revisão da criptografia de dados de conta e PIN, e avaliação da lógica de atestação e monitoramento. O objetivo é chegar à avaliação laboratorial com as evidências prontas e as lacunas já corrigidas, encurtando o ciclo.
Esse trabalho se conecta ao restante do programa de segurança de pagamentos: pentest mobile do aplicativo, pentest de API das integrações com o backend e segurança em pagamentos da cadeia como um todo. Para quem também precisa organizar o ambiente de retaguarda, a adequação ao PCI DSS roda em paralelo. Conheça a abordagem completa em preparação para PCI MPoC e SoftPOS.
A Berghem é uma empresa de pentest brasileira, sediada em São Paulo, que executa testes de invasão manuais orientados por objetivo adversarial.
Perguntas frequentes
MPoC substitui o PCI DSS?
Não. O MPoC trata da solução que aceita o pagamento no dispositivo de consumo; o PCI DSS trata do ambiente que processa, armazena ou transmite os dados de cartão no backend. São padrões complementares. Uma operação de SoftPOS madura mantém a solução MPoC validada na ponta e o ambiente de retaguarda em conformidade com o PCI DSS.
Preciso de MPoC se só uso pagamento por aproximação, sem PIN?
Depende do produto, mas o MPoC é o caminho atual. Ele foi criado para unificar os cenários que antes eram cobertos por SPoC (PIN) e CPoC (aproximação) em um único padrão modular. O MPoC é o padrão mais recente e abrangente; SPoC e CPoC continuam publicados, mas novas soluções que combinam aproximação e PIN tendem a ser avaliadas sob o MPoC, ativando apenas os módulos aplicáveis.
Quem emite a validação PCI MPoC?
A validação é feita por um laboratório reconhecido pelo PCI SSC, não por autoavaliação. O avaliador testa a solução ou o componente contra os objetivos de segurança do padrão e, uma vez aprovado, o produto passa a constar na lista pública de produtos validados do PCI SSC, com atestação e monitoramento contínuos em operação.