Conheça o relato do engenheiro Ígor Brasileiro, que ajudou a implementar o Pix na VTEX, e quais foram as decisões de negócio que nortearam o desenvolvimento.
O Pix, nova forma de realizar pagamentos virtualmente no Brasil, foi criado pelo Branco Central (Bacen) em novembro de 2020, bem próximo da Black Friday – o que trazia o desafio extra de manter a plataforma intacta com a expectativa de um volume maior de vendas.
Apesar de ter sido anunciado alguns meses antes, tivemos apenas 30 dias para implementar o Pix na VTEX, pois o BACEN só fechou algumas definições críticas em outubro. Felizmente, estávamos preparados, mas tivemos que tomar algumas decisões de negócio importantes no caminho – e esperar que o Bacen decidisse mais alguns aspectos do Pix para concluir o desenvolvimento, o que exigiu tocarmos várias frentes em paralelo.
A maturidade tecnológica que existe na VTEX foi o fator que mais contribuiu para implementarmos o Pix tão rapidamente. Para fazer essa entrega com agilidade e segurança, a equipe de engenharia contou com:
Tínhamos a preocupação de implementar o Pix de forma eficiente, tanto para os consumidores que o utilizariam como meio de pagamento, quanto para a plataforma da VTEX, mantendo a integridade do sistema.
Assim, decidimos usar a plataforma do VTEX IO porque, além de ser robusta e resiliente, dispõe de abstrações de código de funcionalidades da VTEX. E também não precisamos nos preocupar com infraestrutura. Como o checkout ia buscar esse script do Pix, bastava criar um proxy muito simples, diminuindo a quantidade de dados que chegava na interface do consumidor final e evitando trafegar dados desnecessários, não consumindo muito da internet do usuário final.
Este projeto envolvia mexer no módulo de pagamentos e do checkout, e nós do time de pagamentos tínhamos liberdade para realizar as mudanças de código, com o auxílio, testes e validação pelo time do checkout. Esse modelo de trabalho, com grande autonomia das equipes de desenvolvimento, também conferiu agilidade ao projeto.
Enquanto, aguardávamos o Bacen liberar algumas definições com relação ao mobile (se iria existir ou não código copia e cola no fluxo de pagamento mobile, por exemplo), começamos a criar as telas e componentes React que provavelmente não teriam mudanças muito grandes. Eram componentes para dispositivos desktop, como a imagem do QR Code, o temporizador, as iterações com as APIs do checkout e a estratégia de polling que é responsável por identificar se o pagamento foi realizado na plataforma da VTEX.
O desenvolvimento era feito num ambiente de sandbox do time de pagamento.
Chegou um momento em que precisamos decidir como trafegar a imagem do QR Code de forma segura e escalável. Estávamos entre duas opções: via link de imagem ou base64 (um padrão para codificar dados em formato de texto).
Usar o link de imagem implicaria lidar com questões de segurança no navegador relacionadas a Cross-origin resource sharing (CORS), como conhecer e registrar os domínios de todos os parceiros para garantir que as imagens baixadas seriam confiáveis. Decidimos então trafegar a imagem do QR Code via base64.
Em paralelo, o time de documentações lançou a documentação técnica explicando o que os provedores de pagamento precisavam enviar para a VTEX e como se integravam para estabelecer a comunicação e que o fluxo de pagamento pudesse ser finalizado.
Decidimos também utilizar um proxy para remover os dados que a API do gateway retornava para UI, a fim de reduzir a quantidade de dados desnecessários passados para o usuário no polling e aumentar a segurança e eficiência.
Houve discussões em como poderíamos mitigar a falta de sincronia de relógios entre o gateway de pagamento e a UI para o consumidor final. Decidimos ter um tempo maior de pagamento no gateway, de forma que a UI sempre teria menos tempo do que o valor configurado no gateway. O objetivo era fazer com que o usuário final tivesse uma experiência melhor, fluida.
Configuramos um tempo de cinco minutos, inicialmente. Expirado esse tempo, se a pessoa ainda estivesse interessada no produto, precisaria finalizar a compra novamente. A tela de pagamento não realizado que tínhamos pedia que o consumidor preenchesse novamente alguns dados. Só que no Pix, isso não é necessário. Adaptamos a tela existente para não exibir a mensagem de “Houve erro…, por favor preencha os dados novamente” quando o pagamento fosse do PIX.
Após uma semana de funcionamento do Pix, recebemos feedback dos varejistas avisando que o tempo de cinco minutos era muito curto. Com isso, alteramos rapidamente a configuração do meio de pagamento, passando de 5 para 15 minutos de espera.
Apesar de curta e relativamente simples, por conta da flexibilidade e robustez da nossa plataforma, a implementação do Pix na VTEX deixou um legado importante.
Por conta da demanda do Pix, criamos uma nova funcionalidade na VTEX, a fim de configurar o tempo de processamento do pagamento. Assim, é o lojista quem decide quantos minutos quer esperar até a transação expirar, caso o usuário final não realize o pagamento.
Também percebemos que muitas lojas utilizavam uma versão antiga do checkout. Então, trouxemos a funcionalidade do fluxo de pagamento, já com o Pix, para essa versão.
No âmbito pessoal, foi um projeto interessantíssimo de trabalhar. Com ele, aperfeiçoei meus conhecimentos sobre fluxo de pagamento, sobre o builder de node e a infraestrutura do VTEX IO, além de alguns conhecimentos sobre cache e CDN.
Agora já estou em outra equipe, mas o projeto do Pix com certeza marcou minha trajetória na VTEX.
Se você gostou dessa história e deseja fazer parte do próximo capítulo dela, venha fazer parte da equipe de desenvolvimento da VTEX. Acesse careers.vtex.com.
A CCX Company em colaboração com a VTEX Commerce Cloud expressa sua gratidão por ter tido a oportunidade de enriquecer seu entendimento acerca das vantagens, tendências e demais elementos abordados no presente tema. Este artigo foi elaborado pela VTEX Commerce Cloud e é encaminhado até você pela CCX COMPANY
