Documentación da guía de integración segura de software 3D
Guía de integración 3D Secure
A partir do 01.01.2021 implementarase a autenticación de dous factores como requisito obrigatorio para todas as transaccións de pago con tarxeta de comercio electrónico. Para cumprir esta obriga, o
os operadores de redes de tarxetas de crédito utilizarán o chamado procedemento 3D Secure. Para vostede como comerciante, é obrigatorio poder realizar este trámite para os seus clientes desde
01.01.2021. A continuación atoparás unha descrición das distintas formas de integración e de como se debe implementar o procedemento 3D Secure para elas.
Seleccione o método de integración que usa
- Estás a usar o formulario de compra hCO?
- Estás a usar o formulario de compra hPF?
- ¿Procesa os pagos sen usar un formulario proporcionado polo sistema Unzer?
Teña en conta: Tamén é importante de que xeito se fan os débitos ou preautorizacións (reservas). Mesmo se utiliza un formulario de pagamento de Unzer GmbH para o rexistro de datos da tarxeta, o proceso 3D Secure levarase a cabo sen un formulario de pago cando os datos da tarxeta se debitan ou autoricen por primeira vez. Neste caso aplícase a terceira forma de integración sen un formulario proporcionado por Unzer.
Ten en conta tamén:
Se usa pagamentos periódicos (pagos por subscrición), asegúrese de ler a sección "Pago recorrente e seguro en 3D".
Procedemento 3D Secure ao usar o formulario de pago hCO
O formulario de pago hCO xa está deseñado para o procedemento 3D Secure. Non hai ningunha acción adicional necesaria para a implementación do procedemento. Non obstante, vostede
ten que asegurarse de que o seu sistema pode xestionar as respostas correspondentes do noso sistema de pago no caso de que se inicie o proceso 3D Secure. Na resposta asíncrona do
sistema de pagamento ao seu servidor, o resultado da transacción transmítese e debe ser avaliado alí antes dunha devolución URL transmítese ao sistema de pagamento.
Para este propósito débense avaliar os seguintes parámetros.
- CÓDIGO.DEVOLUCIÓN.PROCESAMIENTO = 000.200.000
- PROCESSING.RETURN = Transacción + pendente
- PROCESANDO.RESULTADO = ACK
Explicación: o estado da transacción está "pendente", o parámetro PROCESSING.RESULT
representa só un resultado preliminar. Mentres se leve a cabo o proceso 3D Secure, o estado
permanecer pendente.
O resultado final da transacción é entón
- CÓDIGO.DEVOLUCIÓN.PROCESAMIENTO = 000.000.000
- PROCESANDO.RESULTADO = ACK
or - PROCESSING.RETURN.CODE = irgendein Wert ungleich 000.000.000 ou 000.200.000
- PROCESAMENTO.RESULTADO = NOK
No primeiro caso a transacción completouse con éxito, no segundo caso fallou en xeral. Este último pode ter varias razóns, incluída a negativa a autenticarse. Vai
recibe información máis detallada nos parámetros "PROCESSING.RETURN" e "PROCESSING.RETURN.CODE".
Recomendámoslle que realice unha proba para ambas as mensaxes. Para obter máis información sobre como facer unha proba e que detalles da tarxeta de crédito pode usar para realizar unha proba, consulte a continuación.
Procedemento 3D Secure ao usar o formulario de verificación hPF
O formulario de comprobación de hPF tamén está deseñado para usar xa o procedemento 3DS. Non hai ningunha acción adicional necesaria para a implementación do procedemento. Como se describe
para a implementación de hCO a resposta do sistema de pago ten lugar en dous pasos, razón pola cal o sistema debe comprobar o valor do PROCESSING.RETURN.CODE
parámetro ao procesar a resposta.
Para este propósito débense avaliar os seguintes parámetros.
- CÓDIGO.DEVOLUCIÓN.PROCESAMIENTO = 000.200.000
- PROCESSING.RETURN = Transacción + pendente
- PROCESANDO.RESULTADO = ACK
Explicación: o estado da transacción está "pendente", o parámetro PROCESSING.RESULT só representa un resultado preliminar. Mentres se leve a cabo o proceso 3D Secure, o estado
permanecer pendente.
O resultado final da transacción é entón
- CÓDIGO.DEVOLUCIÓN.PROCESAMIENTO = 000.000.000
- PROCESANDO.RESULTADO = ACK
or - PROCESSING.RETURN.CODE = irgendein Wert ungleich 000.000.000 ou 000.200.000
- PROCESAMENTO.RESULTADO = NOK
No primeiro caso a transacción completouse con éxito, no segundo caso fallou en xeral. Este último pode ter varias razóns, incluída a negativa a autenticarse. Vai
recibe información máis detallada nos parámetros "PROCESSING.RETURN" e "PROCESSING.RETURN.CODE".
Recomendámoslle que realice unha proba para ambas as mensaxes. Para obter máis información sobre como facer unha proba e que detalles da tarxeta de crédito pode usar para realizar unha proba, consulte a continuación.
Procedemento 3D Secure con conexión directa
Se non usa un formulario de pagamento proporcionado por Unzer (antes heidelpay) para procesar os pagos con tarxeta de crédito ou simplemente rexistra unha tarxeta mediante un dos formularios e procesa a preautorización (reserva) ou o cargo como referencia ao rexistro como comunicación directa co sistema de pago, ten que implementar o proceso 3D Secure.
Fluxo de transaccións asíncrono:
Este é un proceso asíncrono no que o servidor recibe un reenvío URL (Redirección URL) do noso sistema de pagamento. O seu servidor debe reenviar ao cliente a isto URL para que poida realizar a autenticación mediante o procedemento 3D Secure. O resultado desta autenticación 3D Secure é comunicado directamente a Unzer polo banco emisor da tarxeta.
Despois da autenticación exitosa, a transacción é procesada no sistema Unzer do xeito que xa sabe enviando ao seu sistema un resultado global ao final, ao que responde
cunha redirección URL. A continuación, o sistema de pago redirixirá ao cliente ao seu sistema mediante esta redirección URL do seu sistema
Ten en conta que: neste fluxo de traballo o teu sistema recibe dúas respostas do sistema de pago:
- Un co estado "pendente" (PROCESSING.RETURN.CODE = 000.200.000 e PROCESSING.RETURN = Transacción + pendente) e os parámetros de redirección ao banco emisor de tarxetas do cliente
- Un co resultado final da débeda ou reserva. Tamén hai dúas redireccións URLMencionáronse neste proceso, un do sistema de pago ao que o cliente ten que ser redirixido para autenticarse no seu banco emisor de tarxetas e outro do seu sistema, ao recibir o resultado final, para redirixir ao cliente ao seu sistema.
Os seguintes cambios faranse no procedemento ordinario. Ten en conta que debido á implementación doutros métodos de pago asíncronos, como Paypal, algúns destes
é posible que xa existan procesos na súa implementación.
- Resposta URL
Na primeira chamada (no 2 no diagrama) ao sistema de pagamento, aparecerá unha "Resposta URL”Debe aprobarse no grupo frontend.
Teña en conta: O parámetro IDENTIFICATION.REFERENCEID só é relevante se fai referencia a un rexistro ou outra transacción xa existente - Redirección de procesamento URL Se se precisa autenticación, unha redirección URL e outros parámetros do grupo de redirección transfírense na resposta do sistema de pago (no 5 no diagrama).
- Reenvío do cliente á redirección URL
Se o grupo de redirección responde cunha redirección URL, o navegador do cliente debe ser redirixido a isto URL (No 6 do diagrama) para realizar a autenticación. Os parámetros adicionais do grupo de redirección deben transferirse ao externo websitio como parámetros POST.
Ten en conta que os parámetros adicionais devólvense no grupo "PROCESSING.REDIRECT.xxx" só con 3D Secure Version 1 (incluso alí o número e o nome poden variar), mentres que con 3D Version 2 só un PROCESSING.REDIRECT.URL como se mostra a continuación devólvese: https://heidelpay.hpcgw.net/AuthService/v1/auth/public/2258_2863FFA4C5241C12E39F37
CCF / run Isto significa que, independentemente do tipo e número de parámetros, o navegador cliente debe redirixir ao PROCESSING.REDIRECT.URL.
A continuación atoparás un código sinxelo example de como se pode executar tal redirección. O parte está destinada a informar aos clientes finais cuxos sistemas non admiten Javascript ou o teñen desactivado. Recomendamos encarecidamente que a redirección se faga dentro da xanela activa do navegador do cliente e que non use ventás emerxentes nin novas ventás do navegador, xa que isto podería
irritar aos clientes e levalos a pechar a páxina á que se redirixen.
- Comprobación de resultados asíncrona
O resultado da autenticación envíase de xeito asíncrono ao seu servidor. O sistema de pago espera un válido URL como resposta. (No 12 e 13 no diagrama). Por éxito ou rexeitado
pagos, un diferente URL pode responder aquí o seu sistema. - Camiño de volta do cliente
O sistema de pagamento redirecciona o cliente ao URL proporcionado polo sistema do comerciante despois de completar o proceso de autenticación e a transacción de pago.
Ten en conta: os pasos 4.) e 5.) continúan exactamente do mesmo xeito que xa está familiarizado coas transaccións NONE 3D Secure existentes.
Pago seguro e recorrente en 3D
A partir do 1 de xaneiro de 2021, 3D Secure será obrigatorio para todas as transaccións con tarxeta de comercio electrónico. Non obstante, dado que isto case non é aplicable aos pagos recorrentes, a banca
os sistemas teñen un fluxo de traballo separado para iso.
Para este propósito, os bancos distinguen entre
- CIT = transaccións inicializadas polo cliente
- MIT = transaccións inicializadas polo comerciante
A primeira transacción dunha tarxeta na súa conta de comerciante debe autenticarse con 3D Secure a partir do 01.01.2021. Esta autenticación exitosa é un requisito obrigatorio en
para poder posteriormente enviar máis reservas na mesma tarxeta sen 3D Secure. Polo tanto, o cliente debe ser reenviado ao seu banco emisor de tarxetas para o primeiro cargo en
de acordo co procedemento descrito anteriormente e autenticarse alí como titular da tarxeta. Se non está previsto un cargo no momento do pedido, por example debido a un período de proba, debe facerse unha reserva (preautorización) de polo menos un euro con 3D Secure en presenza do cliente. Non é necesario capturar esta reserva.
Non obstante, para os clientes existentes non é preciso inventar ningunha autenticación 3D Secure. Se o primeiro cargo correcto tivo lugar antes do 01.01.2021, tamén se pode asumir o rexistro do cliente
autenticáronse correctamente. Para os novos clientes a partir do 01.01.2021, por outra banda, a autenticación 3D Secure é obrigatoria para o primeiro cargo ou reserva (preautorización).
Teña en conta: a este respecto, o sistema bancario mira os datos da tarxeta, non os datos do cliente. Polo tanto, se un cliente existente usa unha tarxeta nova despois do 01.01.2021, por exemploample porque o anterior
un caducou ou porque cambiou o banco emisor da tarxeta, este é un novo ciclo recorrente desde o punto de vista dos bancos. view e debe estar autenticado con 3D Secure para a primeira reserva.
Unha vez realizada con éxito esta autenticación inicial, todas as transaccións adicionais quedan exentas da obriga de usar 3D Secure. Polo tanto, os requisitos previos para o pago recorrente sen 3D Secure son:
- Hai polo menos unha débito ou reserva con éxito (preautorización) que se realizou con 3D Secure ou se realizou antes do 01.01.2021.
- refírese a un rexistro xa existente e débito ao enviar
Para informar ao sistema de pago de que se trata dun pago recorrente, tamén se debe enviar o parámetro RECURRENCE.MODE = REPEATED. Isto sinala ao sistema que a
O pagamento recorrente debe comunicarse aos sistemas bancarios.
Teña en conta que: Se se introduce o parámetro RECURRENCE.MODE = REPEATED cando se carga por primeira vez unha nova tarxeta, o reenvío 3D Secure realizarase a pesar deste parámetro.
Probando a implementación 3D Secure
Podes probar a conexión 3D Secure en calquera momento a través do noso sistema de pago. Para facelo, use o modo "CONNECTOR_TEST" para unha transacción, como se mostra no exampos arriba.
Datos de conexión para esta proba:
| SEGURIDADE. REMITENTE | 31HA07BC8142C5A171745D00AD63D182 |
| USUARIO.LOGIN | 31ha07bc8142c5a171744e5aef11ffd3 |
| USUARIO.PWD | 93167DE7 |
| TRANSACCIÓN.CANAL | 31HA07BC8142C5A171749A60D979B6E4 |
| Moedas configuradas para 3D versión 2 | EUR, USD, SEK |
| Moedas configuradas para 3D versión 1 | GBP, CZK, CHF |
O punto final da pasarela do sistema é calquera
Pasarela SGW:
- https://test-heidelpay.hpcgw.net/sgw/gtw - codificación latina-15
- https://test-heidelpay.hpcgw.net/sgw/gtwu - codificado UTF-8
Pasarela NGW:
- https://test-heidelpay.hpcgw.net/ngw/post
Datos da tarxeta de crédito para esta proba:
| marcas | números de tarxeta | CVV | data de caducidade | nota |
| MasterCard | 5453010000059543 | 123 | data futura | 3D - contrasinal: secret3 |
| Visa | 4711100000000000 | 123 | data futura | 3DS - contrasinal: segredo! 33 |
Ten en conta: para 3D Secure Version 2, non precisa introducir un contrasinal, senón que fai clic na ligazón "Fai clic aquí para completar a autenticación.
O único xeito de simular un erro con 3D Secure Version 2 é deixar que a páxina coa ligazón esgote o tempo de espera (aprox. 18 minutos).
Ler máis sobre este manual e descargar PDF:
Documentos/Recursos
 |
Guía de integración de software 3D Secure [pdfDocumentación Unzer, Guía de integración, 3D Secure |
