Documentação do Guia de Integração Segura de Softwares 3D
Guia de integração 3D Secure
A partir de 01.01.2021/XNUMX/XNUMX, a autenticação de dois fatores será implementada como um requisito obrigatório para todas as transações de pagamento com cartão de comércio eletrônico. Para cumprir esta obrigação, o
as operadoras de redes de cartão de crédito utilizarão o chamado procedimento 3D Secure. Para você, como comerciante, é obrigatório poder realizar este procedimento para seus clientes de
01.01.2021. A seguir você encontrará uma descrição das diferentes formas de integração e como o procedimento 3D Secure deve ser implementado para elas.
Selecione o método de integração que você usa
- Você está usando o formulário de checkout hCO?
- Você está usando o formulário de checkout hPF?
- Você processa pagamentos sem usar um formulário fornecido pelo sistema Unzer?
Observe: Também é importante a forma como os débitos ou pré-autorizações (reservas) são feitos. Mesmo que você use um formulário de pagamento da Unzer GmbH para o registro dos dados do cartão, o processo 3D Secure será realizado sem um formulário de checkout quando os dados do cartão forem debitados ou autorizados pela primeira vez. Neste caso, aplica-se a terceira forma de integração sem um formulário fornecido pela Unzer.
Observe também:
Se você usar pagamentos recorrentes (pagamentos de assinatura), certifique-se de ler a seção “3D Secure and Recurring Payment”.
Procedimento 3D Secure ao usar o formulário de verificação da hCO
O formulário de verificação do hCO já foi projetado para o procedimento 3D Secure. Não é necessária nenhuma ação adicional da sua parte para a implementação do procedimento. No entanto, você
tem que se certificar de que seu sistema pode lidar com as respostas correspondentes de nosso sistema de pagamento, caso o processo 3D Secure seja iniciado. Na resposta assíncrona do
sistema de pagamento para o seu servidor, o resultado da transação é transmitido e deve ser avaliado lá antes de uma devolução URL é transmitido para o sistema de pagamento.
Para este propósito, os seguintes parâmetros devem ser avaliados.
- PROCESSAMENTO.DEVOLUÇÃO.CÓDIGO = 000.200.000
- PROCESSING.RETURN = Transação + pendente
- PROCESSAMENTO.RESULTADO = ACK
Explicação: O status da transação é “pendente”, o parâmetro PROCESSING.RESULT
representa apenas um resultado preliminar. Enquanto o processo 3D Secure é realizado, o status
permanecem pendentes.
O resultado final da transação é então
- PROCESSAMENTO.DEVOLUÇÃO.CÓDIGO = 000.000.000
- PROCESSAMENTO.RESULTADO = ACK
or - PROCESSING.RETURN.CODE = irgendein Wert ungleich 000.000.000 orer 000.200.000
- PROCESSAMENTO.RESULTADO = NOK
No primeiro caso, a transação foi concluída com sucesso, no segundo caso, ela falhou globalmente. Este último pode ter vários motivos, incluindo a recusa de autenticação. Você irá
receba informações mais detalhadas nos parâmetros “PROCESSING.RETURN” e “PROCESSING.RETURN.CODE”.
Recomendamos que você execute um teste para ambas as mensagens. Para obter mais informações sobre como fazer um teste e quais detalhes do cartão de crédito você pode usar para um teste, consulte abaixo.
Procedimento 3D Secure ao usar o formulário de verificação hPF
O formulário de verificação hPF também foi projetado para usar o procedimento 3DS. Não é necessária nenhuma ação adicional da sua parte para a implementação do procedimento. Conforme descrito
para a implementação do hCO a resposta do sistema de pagamento ocorre em duas etapas, por isso seu sistema deve verificar o valor do PROCESSING.RETURN.CODE
parâmetro ao processar a resposta.
Para este propósito, os seguintes parâmetros devem ser avaliados.
- PROCESSAMENTO.DEVOLUÇÃO.CÓDIGO = 000.200.000
- PROCESSING.RETURN = Transação + pendente
- PROCESSAMENTO.RESULTADO = ACK
Explicação: O status da transação é “pendente”, o parâmetro PROCESSING.RESULT representa apenas um resultado preliminar. Enquanto o processo 3D Secure é realizado, o status
permanecem pendentes.
O resultado final da transação é então
- PROCESSAMENTO.DEVOLUÇÃO.CÓDIGO = 000.000.000
- PROCESSAMENTO.RESULTADO = ACK
or - PROCESSING.RETURN.CODE = irgendein Wert ungleich 000.000.000 orer 000.200.000
- PROCESSAMENTO.RESULTADO = NOK
No primeiro caso, a transação foi concluída com sucesso, no segundo caso, ela falhou globalmente. Este último pode ter vários motivos, incluindo a recusa de autenticação. Você irá
receba informações mais detalhadas nos parâmetros “PROCESSING.RETURN” e “PROCESSING.RETURN.CODE”.
Recomendamos que você execute um teste para ambas as mensagens. Para obter mais informações sobre como fazer um teste e quais detalhes do cartão de crédito você pode usar para um teste, consulte abaixo.
Procedimento 3D Secure com conexão direta
Se você não usar um formulário de pagamento fornecido pela Unzer (anteriormente heidelpay) para processar pagamentos com cartão de crédito, ou se você simplesmente registrar um cartão usando um dos formulários e processar a pré-autorização (reserva) ou débito como referência ao registro como um comunicação direta com o sistema de pagamento, você deve implementar o processo 3D Secure.
Fluxo de transação assíncrona:
Este é um processo assíncrono em que seu servidor recebe um encaminhamento URL (Redirecionar URL) do nosso sistema de pagamento. Seu servidor deve encaminhar o cliente para este URL para que ele possa realizar a autenticação via procedimento 3D Secure. O resultado dessa autenticação 3D Secure é relatado diretamente ao Unzer pelo banco emissor do cartão.
Após a autenticação bem-sucedida, a transação é processada no sistema Unzer da maneira que você já conhece, enviando ao seu sistema um resultado geral no final, ao qual você responde
com um redirecionamento URL. O sistema de pagamento irá redirecionar o cliente de volta ao seu sistema usando este redirecionamento URL do seu sistema
Observação: neste fluxo de trabalho, seu sistema recebe duas respostas do sistema de pagamento:
- Um com o status “pendente” (PROCESSING.RETURN.CODE = 000.200.000 e PROCESSING.RETURN = Transação + pendente) e os parâmetros de redirecionamento para o banco emissor do cartão do cliente
- Um com o resultado final do débito ou reserva. Existem também dois redirecionamentos URLé mencionado neste processo, um do sistema de pagamento para o qual o cliente deve ser redirecionado para autenticar no banco emissor do cartão e um do seu sistema, ao receber o resultado final, para redirecionar o cliente de volta ao seu sistema.
As seguintes alterações serão feitas no procedimento regular. Por favor, note que devido à implementação de outros métodos de pagamento assíncronos, como Paypal, alguns destes
processos podem já existir em sua implementação.
- Resposta URL
Na primeira chamada (nº 2 no diagrama) para o sistema de pagamento, uma “Resposta URL”Deve ser passado no grupo de front-end.
Observe: O parâmetro IDENTIFICATION.REFERENCEID só é relevante se você se referir a um registro ou outra transação já existente - Processando Redirecionamento URL Se a autenticação for necessária, um redirecionamento URL e outros parâmetros no grupo de redirecionamento são transferidos na resposta do sistema de pagamento (Nº 5 no diagrama).
- Encaminhamento do cliente para o redirecionamento URL
Se o grupo de redirecionamento está respondendo com um redirecionamento URL, o navegador do cliente deve ser redirecionado para este URL (Nº 6 no diagrama) para realizar a autenticação. Os parâmetros adicionais do grupo de redirecionamento devem ser transferidos para o externo website como parâmetros POST.
Observação: Parâmetros adicionais são retornados no grupo “PROCESSING.REDIRECT.xxx” apenas com 3D Secure Versão 1 (mesmo lá o número e a nomenclatura podem variar), enquanto que com 3D Versão 2 apenas um PROCESSING.REDIRECT.URL conforme exibido abaixo é retornado: https://heidelpay.hpcgw.net/AuthService/v1/auth/public/2258_2863FFA4C5241C12E39F37
CCF / run Isso significa que independentemente do tipo e número de parâmetros, o navegador do cliente deve redirecionar para PROCESSING.REDIRECT.URL.
Abaixo você encontrará um código simples examparquivo de como tal redirecionamento pode ser executado. o parte destina-se a informar os clientes finais cujos sistemas não suportam Javascript ou o têm desativado. Recomendamos fortemente que o redirecionamento seja feito dentro da janela ativa do navegador do cliente e não use janelas pop-up ou novas janelas do navegador, pois isso poderia
irritar os clientes e levá-los a fechar a página para a qual são redirecionados.
- Verificação de resultado assíncrono
O resultado da autenticação é enviado de forma assíncrona para o seu servidor. O sistema de pagamento espera um válido URL como resposta. (Nº 12 e 13 no diagrama). Para bem-sucedido ou rejeitado
pagamentos, um diferente URL pode ser respondido aqui pelo seu sistema. - Caminho de retorno do cliente
O sistema de pagamento redireciona o cliente para o URL fornecido pelo sistema do estabelecimento comercial após o processo de autenticação e a transação de pagamento terem sido concluídos.
Observe: as etapas 4.) e 5.) procedam exatamente da mesma maneira que já está familiarizado nas transações NENHUMA 3D Secure existentes.
Pagamento 3D Seguro e Recorrente
A partir de 1º de janeiro de 2021, o 3D Secure será obrigatório para todas as transações com cartão de comércio eletrônico. No entanto, uma vez que isso dificilmente é aplicável para pagamentos recorrentes, o banco
os sistemas têm um fluxo de trabalho separado para isso.
Para este efeito, os bancos distinguem entre
- CIT = transações inicializadas pelo cliente
- MIT = transações inicializadas pelo comerciante
A primeira transação de um cartão em sua conta de comerciante deve ser autenticada com 3D Secure a partir de 01.01.2021/XNUMX/XNUMX. Essa autenticação bem-sucedida é um requisito obrigatório em
para ser capaz de submeter posteriormente mais reservas no mesmo cartão sem 3D Secure. O cliente deve, portanto, ser encaminhado ao banco emissor do cartão para o primeiro débito em
de acordo com o procedimento descrito acima e se autenticar como titular do cartão. Se um débito não for planejado no momento do pedido, por exampDevido a um período de teste, uma reserva (pré-autorização) de pelo menos um euro deve ser feita com 3D Secure na presença do cliente. A captura desta reserva não é necessária.
Para os clientes existentes, no entanto, nenhuma autenticação 3D Secure precisa ser feita. Se o primeiro débito bem-sucedido ocorreu antes de 01.01.2021/XNUMX/XNUMX, o registro do cliente também pode ser assumido como
foram autenticados com sucesso. Já para novos clientes a partir de 01.01.2021, a autenticação 3D Secure é obrigatória para o primeiro débito ou reserva (pré-autorização).
Observação: a esse respeito, o sistema bancário analisa os dados do cartão, não os dados do cliente. Portanto, se um cliente existente usar um novo cartão após 01.01.2021/XNUMX/XNUMX, por example porque o anterior
um expirou ou porque mudou o banco emissor do cartão, este é um novo ciclo recorrente do ponto dos bancos de view e deve ser autenticado com 3D Secure para a primeira reserva.
Uma vez que esta autenticação inicial tenha sido realizada com sucesso, todas as transações futuras estão isentas da obrigação de usar 3D Secure. Os pré-requisitos para pagamento recorrente sem 3D Secure são, portanto:
- Há pelo menos um débito ou reserva bem-sucedido (pré-autorização) que foi realizado com 3D Secure ou antes de 01.01.2021/XNUMX/XNUMX.
- é referenciado a um registro existente e débito no momento do envio
Para que o sistema de pagamento saiba que se trata de um pagamento recorrente, deve ser enviado também o parâmetro RECURRENCE.MODE = REPEATED. Isso sinaliza para o sistema que um
o pagamento recorrente deve ser reportado aos sistemas bancários.
Nota: Se o parâmetro RECURRENCE.MODE = REPEATED for inserido quando um novo cartão for carregado pela primeira vez, o encaminhamento 3D Secure será executado apesar deste parâmetro.
Testando a implementação 3D Secure
Você pode testar a conexão 3D Secure a qualquer momento por meio de nosso sistema de pagamento. Para fazer isso, use o modo “CONNECTOR_TEST” para uma transação, conforme mostrado no examples acima.
Dados de conexão para este teste:
| SEGURANÇA.REMETENTE | 31HA07BC8142C5A171745D00AD63D182 |
| LOGIN DE USUÁRIO | 31ha07bc8142c5a171744e5aef11ffd3 |
| USUÁRIO.PWD | 93167DE7 |
| TRANSAÇÃO.CANAL | 31HA07BC8142C5A171749A60D979B6E4 |
| Moedas configuradas para 3D versão 2 | EUR, USD, SEK |
| Moedas configuradas para 3D versão 1 | GBP, CZK, CHF |
O ponto final do gateway do sistema é
Gateway SGW:
- https://test-heidelpay.hpcgw.net/sgw/gtw - Codificado em Latim-15
- https://test-heidelpay.hpcgw.net/sgw/gtwu - codificado em UTF-8
Gateway NGW:
- https://test-heidelpay.hpcgw.net/ngw/post
Dados do cartão de crédito para este teste:
| marcas | números de cartão | CVV | data de validade | observação |
| MasterCard | 5453010000059543 | 123 | data futura | 3D - senha: secret3 |
| Visa | 4711100000000000 | 123 | data futura | 3DS - senha: segredo! 33 |
Observação: Para o 3D Secure Versão 2, você não precisa inserir uma senha, basta clicar no link ”Clique aqui para concluir a autenticação.
A única maneira de simular um erro com o 3D Secure Versão 2 é deixar a página com o link expirar (aproximadamente 18 minutos).
Leia mais sobre este manual e baixe o PDF:
Documentos / Recursos
 |
Guia de Integração Segura de Softwares 3D [pdf] Documentação Unzer, Guia de Integração, 3D Secure |
