por Filipe Abelha Nos últimos posts falamos sobre as características e a estrutura de documentos XML. Da mesma forma que já abordamos a integração pop-up com POST/FORM (aqui, aqui e aqui), vamos aproveitar que já possuímos embasamento para falar de mais uma forma de integração entre os ecommerces e o meio de pagamento disponibilizado pela iVarejo: o pop-up com POST/XML. O controle do processo de pagamento acontece no domínio da iVarejo, retirando grande parte da complexidade de implementação necessária dos outros modelos (de forma análoga ao pop-up com POST/FORM). As lojas virtuais, hotsites e ecommerces que adotarem este padrão encapsularão os dados de seus formulários em um documento XML antes do envio para a iVarejo. Fluxo de execução O fluxo de sequência de troca de mensagens acontece na seguinte ordem:  A estrutura das mensagens trocadas entre o ecommerce e a iVarejo já estão bem detalhadas na documentação (aqui), então vamos focar em definir o conteúdo de cada uma delas e a motivação para a existência de cada método. 1 - Serviço "entradapedido.wsvc": - recebe a mensagem "EnvioMeioPagamento" que possui as informações referentes ao pedido, assim como os dados do consumidor que o está realizando. - retorna a mensagem "RetornoMeioPagamento" que possui informações referentes à autorização do meio de pagamento. 2 - Se o retorno for de pagamento autorizado, o ecommerce chama a página Pagamento.aspx, onde o consumidor confirma os seus dados, escolhe o plano de pagamento e efetiva a compra. Após a ação do consumidor, o ambiente da iVarejo retorna a navegação para o ecommerce. 3 - Serviço "retornoprocessamentopedido.wsvc": - recebe a mensagem "RequisicaoStatusPagamento" com o id da transação realizada. - retorna a mensagem "RetornoMeioPagamento", que agora possui status de concluído (caso o consumidor tenha finalizado o processo com sucesso) ou de cancelado (caso o consumidor tenha cancelado o processo em qualquer etapa). O ecommerce deverá tratar os retornos de acordo com os seus status: - IVJ.ECOMMERCE.RET.001: meio de pagamento autorizado. O processo deve ter prosseguimento. - IVJ.ECOMMERCE.RET.002: processo de compra concluído. - IVJ.ECOMMERCE.RET.003: processo de compra cancelado. - IVJ.ECOMMERCE.RET.004: meio de pagamento não autorizado. - IVJ.ECOMMERCE.RET.100: envio de segunda via realizado com sucesso. Para os casos em que o consumidor solicite uma segunda via de seus boletos, o ecommerce deve implementar uma funcionalidade que acessa o serviço "segundaviaboletos.wsvc": - recebe a mensagem "DadosSegundaViaBoletos" que possui a identificação do ecommerce e do pedido. - retorna a mensagem "RetornoMeioPagamento" com o código de retorno correspondente. Nos próximos posts forneceremos exemplos de integração em ASP .NET e ASP. tags: #integracao, #xml Fontes: --- |
Blog >