Blog‎ > ‎

‎Integração Pop-Up com Post/XML‎ (parte I)

postado em 21 de nov de 2011 05:32 por Usuário desconhecido   [ 30 de abr de 2012 08:28 atualizado‎(s)‎ ]
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:

---
Comments