FAQ — Nova integração do MPI Cielo

O MPI V3 é o novo modelo de integração do plugin de autenticação 3DS da Cielo. Ele opera exclusivamente no modelo server-to-server: o estabelecimento controla todas as chamadas à API no back-end, incluindo a exibição do desafio ao portador quando necessário.

Não. O MPI V3 é uma evolução do plugin de integração, não do protocolo. As versões do protocolo 3DS continuam as mesmas:

O MPI V3 é exclusivo para clientes com certificação PCI DSS que tenham o produto 3DS habilitado na Cielo.

A integração V2 será descontinuada. A migração para o MPI V3 é obrigatória para todos os estabelecimentos que utilizam autenticação 3DS. Respeite o prazo que será informado pela Cielo para evitar interrupção no processamento de pagamentos.

Não diretamente. A experiência do portador permanece a mesma: o desafio 3DS continua sendo exibido quando necessário, sem alteração visual ou de comportamento para o comprador. O que muda é a implementação no back-end e no front-end do estabelecimento.

Não. As credenciais (ClientId e ClientSecret) usadas para gerar o access_token são as mesmas. O que muda é o endpoint de AUTH: de /v2/auth/token para /v3/auth/token.

Não é recomendado rodar os dois modelos simultaneamente para o mesmo pedido. Os scripts são incompatíveis entre si. Planeje a migração como uma substituição completa: remova os scripts e classes V2 e implemente o fluxo V3 integralmente.

Transações iniciadas com a V2 devem ser concluídas com a V2. Não valide com V3 uma autenticação iniciada com V2. Planeje a ativação da V3 em um momento de baixo volume para minimizar o impacto.

Depende da implementação atual. De forma geral:

• Front-end: remova os inputs com classes bpmpi_*, substitua os scripts e implemente a inicialização via MPI.load() e MPI.init().
• Back-end: mova a geração do access_token e as chamadas de ENROLL e VALIDATE para o servidor, caso ainda não estejam lá. Atualize o endpoint de AUTH.

A migração envolve mudança de paradigma (de front-end para server-to-server). Planeje tempo de desenvolvimento, testes e homologação.

O sandbox é o ambiente de testes. Use-o para validar a integração antes de ir para produção. Transações em produção são reais, geram custos e podem resultar em penalizações pelas bandeiras e pelos emissores.

Inclua os dois scripts abaixo no ambiente correspondente:

• mpi.js — responsável pela inicialização da sessão, atualização do cartão e exibição do desafio;
• mpiHelpers.js — fornece utilitários como getBrowserInfo e o builder de pedido.

Consulte a documentação Etapa 1 – Preparar o front-end para ver os endereços completos

As credenciais são geradas através do site Cielo. Saiba mais em: Obter as credenciais 3DS

Importante: para clientes do Gateway de Pagamentos, as credenciais do 3DS não são geradas no portal do Gateway, mas sim no Portal E-commerce.

Saiba mais em: Como gerar a credencial 3DS?

São dois tokens distintos com finalidades diferentes:

Importante: nunca exponha o access_token no front-end.

O access_token tem validade de 20 minutos (1.200 segundos) em produção. Se ele expirar antes de a sequência ser concluída, as chamadas subsequentes retornarão 401. Nesse caso, gere um novo access_token e reinicie o fluxo desde o AUTH.

Para evitar esse cenário, gere um novo access_token a cada sessão de compra e monitore o campo expires_in da resposta AUTH.

Gere um novo access_token chamando novamente a operação AUTH e reinicie o fluxo.