Documentación de la guía de integración de software 3D Secure
Guía de integración 3D Secure
A partir del 01.01.2021 en adelante, la autenticación de dos factores se implementará como requisito obligatorio para todas las transacciones de pago con tarjeta de comercio electrónico. Para cumplir con esta obligación, el
Los operadores de redes de tarjetas de crédito utilizarán el llamado procedimiento 3D Secure. Para usted como comerciante es obligatorio poder realizar este trámite para sus clientes desde
01.01.2021. A continuación encontrará una descripción de las diferentes formas de integración y cómo se debe implementar el procedimiento 3D Secure para ellas.
Por favor seleccione el método de integración que utiliza
- ¿Estás utilizando el formulario de pago hCO?
- ¿Estás utilizando el formulario de pago hPF?
- ¿Procesan pagos sin utilizar un formulario proporcionado por el sistema Unzer?
Tenga en cuenta: También es importante la forma en que se realizan los débitos o preautorizaciones (reservas). Incluso si utiliza un formulario de pago de Unzer GmbH para el registro de los datos de la tarjeta, el proceso 3D Secure se llevará a cabo sin un formulario de pago cuando los datos de la tarjeta se carguen o autoricen por primera vez. En este caso se aplica la tercera forma de integración sin formulario proporcionado por Unzer.
Tenga en cuenta también:
Si utiliza pagos recurrentes (pagos de suscripción), asegúrese de leer la sección “Pago 3D Seguro y Recurrente”.
Procedimiento 3D Secure al utilizar el formulario de pago de hCO
El formulario de pago de hCO ya está diseñado para el procedimiento 3D Secure. No es necesaria ninguna acción adicional por su parte para la implementación del procedimiento. Sin embargo, tu
Debe asegurarse de que su sistema pueda manejar las respuestas correspondientes de nuestro sistema de pago en caso de que se inicie el proceso 3D Secure. En la respuesta asincrónica del
sistema de pago a su servidor, el resultado de la transacción se transmite y debe evaluarse allí antes de una devolución URL se transmite al sistema de pago.
Para ello se deben evaluar los siguientes parámetros.
- PROCESAMIENTO.CÓDIGO.RETORNO = 000.200.000
- PROCESSING.RETURN = Transacción+pendiente
- PROCESAMIENTO.RESULTADO = ACK
Explicación: El estado de la transacción es “pendiente”, el parámetro PROCESSING.RESULT
representa sólo un resultado preliminar. Mientras se lleve a cabo el proceso 3D Secure, el estado
quedan pendientes.
El resultado final de la transacción es entonces
- PROCESAMIENTO.CÓDIGO.RETORNO = 000.000.000
- PROCESAMIENTO.RESULTADO = ACK
or - PROCESSING.RETURN.CODE = irgendein Wert ungleich 000.000.000 o 000.200.000
- PROCESANDO.RESULTADO = NO OK
En el primer caso la transacción se completó con éxito, en el segundo caso fracasó en general. Esto último puede tener varios motivos, incluida la negativa a autenticarse. Vas a
recibirá información más detallada en los parámetros “PROCESSING.RETURN” y “PROCESSING.RETURN.CODE”.
Le recomendamos que ejecute una prueba para ambos mensajes. Para obtener más información sobre cómo realizar una prueba y qué datos de tarjeta de crédito puede utilizar para una prueba, consulte a continuación.
Procedimiento 3D Secure al utilizar el formulario de pago de hPF
El formulario de pago de hPF también está diseñado para utilizar el procedimiento 3DS. No es necesaria ninguna acción adicional por su parte para la implementación del procedimiento. Como se describe
para la implementación de hCO la respuesta del sistema de pago se realiza en dos pasos, por lo que su sistema debe verificar el valor del PROCESSING.RETURN.CODE
parámetro al procesar la respuesta.
Para ello se deben evaluar los siguientes parámetros.
- PROCESAMIENTO.CÓDIGO.RETORNO = 000.200.000
- PROCESSING.RETURN = Transacción+pendiente
- PROCESAMIENTO.RESULTADO = ACK
Explicación: El estado de la transacción es "pendiente", el parámetro PROCESSING.RESULT representa solo un resultado preliminar. Mientras se lleve a cabo el proceso 3D Secure, el estado
quedan pendientes.
El resultado final de la transacción es entonces
- PROCESAMIENTO.CÓDIGO.RETORNO = 000.000.000
- PROCESAMIENTO.RESULTADO = ACK
or - PROCESSING.RETURN.CODE = irgendein Wert ungleich 000.000.000 o 000.200.000
- PROCESANDO.RESULTADO = NO OK
En el primer caso la transacción se completó con éxito, en el segundo caso fracasó en general. Esto último puede tener varios motivos, incluida la negativa a autenticarse. Vas a
recibirá información más detallada en los parámetros “PROCESSING.RETURN” y “PROCESSING.RETURN.CODE”.
Le recomendamos que ejecute una prueba para ambos mensajes. Para obtener más información sobre cómo realizar una prueba y qué datos de tarjeta de crédito puede utilizar para una prueba, consulte a continuación.
Procedimiento 3D Secure con conexión directa
Si no utiliza un formulario de pago proporcionado por Unzer (anteriormente heidelpay) para procesar pagos con tarjeta de crédito, o si simplemente registra una tarjeta usando uno de los formularios y procesa la preautorización (reserva) o débito como referencia al registro como comunicación directa con el sistema de pago, deberá implementar el proceso 3D Secure.
Flujo de transacciones asincrónicas:
Este es un proceso asincrónico en el que su servidor recibe un reenvío URL (Redirigir URL) de nuestro sistema de pago. Su servidor debe reenviar al cliente a este URL para que pueda realizar la autenticación mediante el procedimiento 3D Secure. El banco emisor de la tarjeta informa directamente a Unzer del resultado de esta autenticación 3D Secure.
Después de una autenticación exitosa, la transacción se procesa aún más en el sistema Unzer de la manera que ya conoce enviando a su sistema un resultado general al final, al que usted responde.
con una redirección URL. Luego, el sistema de pago redirigirá al cliente a su sistema utilizando esta redirección. URL desde su sistema
Tenga en cuenta: en este flujo de trabajo su sistema recibe dos respuestas del sistema de pago:
– Uno con el estado “pendiente” (PROCESSING.RETURN.CODE=000.200.000 y PROCESSING.RETURN=Transacción+pendiente) y los parámetros de redirección al banco emisor de la tarjeta del cliente
– Uno con el resultado final del débito o reserva. También hay dos redirecciones. URLComo se menciona en este proceso, uno del sistema de pago al que se debe redirigir al cliente para autenticarse en el banco emisor de su tarjeta y otro de su sistema, al recibir el resultado final, para redirigir al cliente nuevamente a su sistema.
Se realizarán los siguientes cambios al procedimiento regular. Tenga en cuenta que debido a la implementación de otros métodos de pago asincrónicos, como Paypal, algunos de estos
Es posible que ya existan procesos en su implementación.
- Respuesta URL
En la primera llamada (nº 2 del diagrama) al sistema de pagos, se emite una “Respuesta URL”debe pasarse en el grupo frontend.
Tenga en cuenta: El parámetro IDENTIFICATION.REFERENCEID solo es relevante si se refiere a un registro u otra transacción ya existente. - Redireccionamiento de procesamiento URL Si se requiere autenticación, una redirección URL y otros parámetros en el grupo de redireccionamiento se transfieren en la respuesta del sistema de pago (No. 5 en el diagrama).
- Reenvío del cliente al redireccionamiento URL
Si el grupo de redireccionamiento responde con un redireccionamiento URL, el navegador del cliente debe ser redirigido a este URL (No. 6 en el diagrama) para realizar la autenticación. Los parámetros adicionales del grupo de redireccionamiento deben transferirse al externo websitio como parámetros POST.
Tenga en cuenta: los parámetros adicionales se devuelven en el grupo “PROCESSING.REDIRECT.xxx” solo con 3D Secure Versión 1 (incluso allí el número y el nombre pueden variar), mientras que con 3D Versión 2 solo un PROCESSING.REDIRECT.URL como se muestra a continuación: https://heidelpay.hpcgw.net/AuthService/v1/auth/public/2258_2863FFA4C5241C12E39F37
CCF/run Esto significa que, independientemente del tipo y número de parámetros, el navegador del cliente debe redirigir a PROCESSING.REDIRECT.URL.
A continuación encontrará un código simple ex.amparchivo de cómo se puede ejecutar dicha redirección. El Esta parte está destinada a informar a los clientes finales cuyos sistemas no admiten Javascript o lo tienen deshabilitado. Recomendamos encarecidamente que la redirección se realice dentro de la ventana activa del navegador del cliente y no utilizar ventanas emergentes o nuevas ventanas del navegador, ya que esto podría
irritar a los clientes y llevarlos a cerrar la página a la que son redirigidos.
- Verificación de resultados asincrónica
El resultado de la autenticación se envía de forma asíncrona a su servidor. El sistema de pago espera una válida URL como respuesta. (No. 12 y 13 en el diagrama). Para éxito o rechazo
pagos, una diferente URL su sistema puede responder aquí. - Ruta de regreso del cliente.
El sistema de pago redirige al cliente al URL proporcionado por el sistema del comerciante después de que se hayan completado el proceso de autenticación y la transacción de pago.
Tenga en cuenta: Los pasos 4.) y 5.) proceden exactamente de la misma manera que ya conoce en las transacciones NONE 3D Secure existentes.
Pago 3D Seguro y Recurrente
A partir del 1 de enero de 2021, 3D Secure será obligatorio para todas las transacciones con tarjeta de comercio electrónico. Sin embargo, como esto apenas es aplicable a pagos recurrentes, el banco
Los sistemas tienen un flujo de trabajo separado para esto.
Para ello, los bancos distinguen entre
- CIT = transacciones inicializadas por el cliente
- MIT = transacciones inicializadas por el comerciante
La primera transacción de una tarjeta en su cuenta de comerciante debe autenticarse con 3D Secure a partir del 01.01.2021 en adelante. Esta autenticación exitosa es un requisito obligatorio en
para poder realizar posteriormente más reservas en la misma tarjeta sin 3D Secure. Por lo tanto, el cliente debe ser remitido al banco emisor de su tarjeta para el primer débito en
de acuerdo con el procedimiento descrito anteriormente y autentificarse allí como titular de la tarjeta. Si no se prevé un cargo en el momento del pedido, por ej.ampSi debido a un período de prueba, se deberá realizar una reserva (preautorización) de al menos un euro con 3D Secure en presencia del cliente. La captura de esta reserva no es necesaria.
Sin embargo, para los clientes existentes no es necesario realizar ninguna autenticación 3D Secure. Si el primer débito exitoso tuvo lugar antes del 01.01.2021, también se puede suponer que el registro del cliente
han sido autenticados exitosamente. Para los nuevos clientes a partir del 01.01.2021, en cambio, la autenticación 3D Secure es obligatoria para el primer débito o reserva (preautorización).
Tenga en cuenta: a este respecto, el sistema bancario analiza los datos de la tarjeta, no los datos del cliente. Entonces, si un cliente existente usa una nueva tarjeta después del 01.01.2021, por ej.ample porque el anterior
alguna ha caducado o porque ha cambiado de banco emisor de la tarjeta, se trata de un nuevo ciclo recurrente desde el punto de vista de los bancos. view y debe estar autenticado con 3D Secure para la primera reserva.
Una vez realizada con éxito esta autenticación inicial, todas las transacciones posteriores estarán exentas de la obligación de utilizar 3D Secure. Los requisitos previos para el pago recurrente sin 3D Secure son, por lo tanto:
- Hay al menos un débito o una reserva (preautorización) realizada con éxito con 3D Secure o antes del 01.01.2021.
- se hace referencia a un registro existente y se carga al momento de la presentación
Para que el sistema de pago sepa que se trata de un pago recurrente, también se debe enviar el parámetro RECURRENCE.MODE=REPEATED. Esto indica al sistema que un
el pago recurrente debe ser reportado a los sistemas bancarios.
Tenga en cuenta: si se introduce el parámetro RECURRENCE.MODE=REPEATED cuando se carga una nueva tarjeta por primera vez, se realizará el reenvío 3D Secure a pesar de este parámetro.
Probando la implementación de 3D Secure
Puedes probar la conexión 3D Secure en cualquier momento a través de nuestro sistema de pago. Para hacerlo, use el modo “CONNECTOR_TEST” para una transacción, como se muestra en el ejemploamples de arriba.
Datos de conexión para esta prueba:
| SEGURIDAD.REMITENTE | 31HA07BC8142C5A171745D00AD63D182 |
| INICIO DE SESIÓN DE USUARIO | 31ha07bc8142c5a171744e5aef11ffd3 |
| USUARIO.PWD | 93167DE7 |
| CANAL. DE TRANSACCIÓN | 31HA07BC8142C5A171749A60D979B6E4 |
| Monedas configuradas para 3D Versión 2 | EUR, USD, SEK |
| Monedas configuradas para 3D Versión 1 | GBP, corona checa, franco suizo |
El punto final de la puerta de enlace del sistema es
Puerta de enlace SGW:
– https://test-heidelpay.hpcgw.net/sgw/gtw – Codificado en latín 15
– https://test-heidelpay.hpcgw.net/sgw/gtwu – Codificado UTF-8
Puerta de enlace NGW:
– https://test-heidelpay.hpcgw.net/ngw/post
Datos de la tarjeta de crédito para esta prueba:
| marcas | números de tarjeta | CVV | fecha de caducidad | nota |
| tarjeta MasterCard | 5453010000059543 | 123 | fecha futura | 3D – contraseña: secreta3 |
| Visa | 4711100000000000 | 123 | fecha futura | 3DS – contraseña: secreta!33 |
Tenga en cuenta: para 3D Secure Versión 2, no necesita ingresar una contraseña, simplemente haga clic en el enlace "Haga clic aquí para completar la autenticación".
La única forma de simular un error con 3D Secure Versión 2 es dejar que la página con el enlace expire (aproximadamente 18 minutos).
Lea más sobre este manual y descargue el PDF:
Documentos / Recursos
 |
Guía de integración segura de software 3D [pdf] Documentación Unzer, Guía de integración, 3D Secure |
