Eu havia comentado em algum artigo anterior, que este ano, seria de muitos desafios. Daqueles que realmente te tiram da zona de conforto. Meu primeiro grande projeto na empresa, era integrar um sistema com o PagSeguro, um gateway de pagamento bastante utilizado no Brasil.
\nA plataforma era para um Ambiente de Coworking, e será possível realizar comprar de eventos, assinaturas de planos, entre outros serviços. No início fiquei intimidado pela tempo do deadline, mas busquei fazer o melhor, e logo recalibrei o foco.
\nPara o artigo não ficar muito grande, dividirei o mesmo em três partes. Sendo está a primeira parte.
\nComo deve ser, busquei junto com meu coordenador planejar as atividades. Analisei o escopo, o protótipo e a API do PagSeguro para dar inicio ao planejamento. Com o suporte do coordenador, planejei a arquitetura do fluxo de pagamento, baseado também na estrutura idealizada no projeto.
\nO módulo que estava implementando, era o de compra de um Evento, que envolvia a compra pelas três formas de pagamento, Cartão de Crédito, débito online e boleto. Mas vou me atentar nessa sessão sobre o planejamento, depois volto para os detalhes de implementação do PagSeguro.
\nPara planejar o módulo de pagamento, criei um diagrama de atividades, ou mais conhecido como UML. É um modelo para prototipação de atividades, seguindo a lógica do fluxo de uma funcionalidade ou mais de uma. Segue abaixo o diagrama criado:
\nDiagrama de Atividades - UML
\nVou seguir explicando o fluxo pensado inicialmente, e depois as pequenas alterações que tive junto com meu coordenador. Apenas como pequena revisão da nomenclatura:
\nPronto, feito um pequeno resumo, agora podemos prosseguir com a explicação.
\nNesse fluxo, possuímos três formas de pagamento, como comentado anteriormente, mas existe um pequeno detalhe a respeito do boleto. Eu tinha dois cenários, um pagamento processado pelo PagSeguro e outro poderia ser colocado pelo cliente no gerenciador da plataforma. Por isso a divisão do fluxo acima.
\nVou iniciar pelo fluxo de cartão de crédito, o usuário deve digitar os campos de cartão de crédito, caso os dados estejam validados ele segue o fluxo, caso contrário ele retorna aos campos.
\nApós validado, realizamos uma chamada a API do PagSeguro pegando todos os dados necessários para realizar a transação. Validamos e caso ocorra algum erro na conexão com a API, retornamos um feedback de erro.
\nApós a validação da transação, salvamos os dados no banco e depois realizamos um disparo ao servidor de e-mail, informando do pedido realizado e do status da transação. No final do processo, ficamos escutando através de um webhook, a atualização de status de uma transação.
\nMostrei para meu coordenador o fluxo, e ele me auxiliou, realizando umas pequenas modificações no fluxo, segue as anotações:
\nAlterações no fluxo
\nNo fluxo dos três pagamentos, temos a validação da sessão do pagseguro, essa foi uma das primeiras modificações. Mantendo o resto de fluxo de feedback e validações. No fluxo de boleto bancário, validamos caso exista um input de e-mail enviado do cliente, caso exista é disparado um e-mail, caso não, seguimos o fluxo salvando os dados no banco e enviando os e-mails com status da transação do PagSeguro.
\nTodo esse fluxo aborta o modelo de pagamento, onde contenta as três formas de pagamento, o armazenando no banco de dados e o disparo de e-mail.
\nNo fluxo de compra de um evento, o usuário poderá se cadastrar no sistema, caso não seja registrado. O formulário comportava alguns campos padrões de usuário, mas faltava informações de endereço. No PagSeguro, para a forma de pagamento com Cartão de Crédito, ter o endereço do pagador, são obrigatórios, onde tive que ter uma conversa com a equipe de Design e requisitos para a pequena modificação.
\nOs requisitos comportavam também, Cartão de Débito, no entanto, no PagSeguro pelo Checkout Transparente, ele permite apenas Débito Online. A transação é realizada pelo banco selecionado, que é disponibilizado pelo PagSeguro também.
\nA última modificação, era a seleção de parcelas, que na seção de cartão de crédito, não comportava a seleção, embora no fluxo, evento deve ser comprado apenas uma vez, era necessário, informado pelo PagSeguro.
\nAlgumas pequenas modificações, que apenas observei durante o desenvolvimento, mas que pude alinhar bem junto com as outras equipes para comportar os dados que iria precisar na integração.
\nPor aqui fizalizamos a primeira parte do artigo.
","timeToRead":3,"frontmatter":{"title":"Integrando com gateway de pagamento - PagSeguro | Parte 1","date":"February 07, 2021","description":"Eu havia comentado em algum artigo anterior, que este ano, seria de muitos desafios. Daqueles que realmente te tiram da zona de conforto. Meu primeiro grande projeto na empresa, era integrar um sistema com o PagSeguro, um gateway de pagamento bastante utilizado no Brasil.","tags":["JAVASCRIPT","GERAL","PHP"]}}},"pageContext":{"slug":"/integrando-com-pagseguro-pt-1/","previous":{"fields":{"slug":"/como-implementar-gitflow/"},"frontmatter":{"title":"Como implementar o GitFlow?","tags":["GIT"]}},"next":{"fields":{"slug":"/globbing-no-shell/"},"frontmatter":{"title":"GLOBBINS NO SHELL (Caracteres-Curinga)","tags":["SHELL"]}},"language":"en","i18n":{"language":"en","languages":["pt","en"],"defaultLanguage":"pt","generateDefaultLanguagePage":false,"routed":true,"originalPath":"/writing/integrando-com-pagseguro-pt-1/","path":"en/writing/integrando-com-pagseguro-pt-1/"}}},"staticQueryHashes":["63159454"]}