1 Configuración de seguridad y procedimientos generales
   1.1 Usuario API
   1.2 Formulario de solicitud
   1.3 Seguridad
      1.3.1 Cifrado
      1.3.2 Dirección IP
      1.3.3 Firma SHA
   1.4 Análisis de respuesta
2 Solicitud de nuevo pedido
   2.1 URL de solicitud
   2.2 Parámetros de solicitud
   2.3 Página de prueba
   2.4 Excluding specific payment methods
   2.5 Solicitud de pedido mediante 3-D Secure
   2.6 Dividir tarjetas de crédito/débito
   2.7 Procesamiento de transacciones con credenciales guardadas
3 Respuesta de pedido
   3.1 Solicitud duplicada
4 Mantenimiento directo
   4.1 Solicitud de mantenimiento
      4.1.1 URL de solicitud
      4.1.2 Parámetros de solicitud
      4.1.3 Página de prueba
   4.2 Respuesta de mantenimiento
   4.3 Solicitud duplicada
5 Consulta directa
   5.1 Solicitud de consulta
      5.1.1 URL de solicitud
      5.1.2 Parámetros de solicitud
      5.1.3 Página de prueba
   5.2 Respuesta de consulta
      5.2.1 Transacciones procesadas con e-Commerce
   5.3 Posibles estados de respuesta
   5.4 Consulta directa como último recurso
6 Solicitud de aviso de privacidad de Controlador de datos
   6.1 URL de solicitud
      6.1.1 Solicitud de consulta
      6.1.2 Parámetros de solicitud
      6.1.3 Página de prueba
   6.2 Respuesta de consulta
7 Excepciones de método de pago
   7.1 Direct Debits
      7.1.1 Domiciliaciones AT
      7.1.2 Domiciliaciones DE (ELV)
      7.1.3 Domiciliaciones NL
   7.2 Métodos de pago con solo mantenimiento a través de DirectLink
8 3-D Secure v1.0
   8.1 Introducción
   8.2 Flujo de transacciones 3-D a través de DirectLink
      8.2.1 Parámetros de solicitud extra
      8.2.2 Campos devueltos adicionales
      8.2.3 Comentarios
9 3-D Secure v2.1
   9.1 Introducción
   9.2 Flujo de transacciones 3-D a través de DirectLink
      9.2.1 Parámetros de solicitud extra
      9.2.2 Campos devueltos adicionales
      9.2.3 3-D Secure v2.1 MasterCard+
      9.2.4 Comentarios
   9.3 Exclusiones y exenciones para 3DsV2
      9.3.1 3DSv2 y exclusiones
      9.3.2 Flujo SCA y 3DS sin fricción/con comprobación
      9.3.3 Indicación del flujo preferido
      9.3.4 Exenciones de 3DS

1 Configuración de seguridad y procedimientos generales

Los siguientes procedimientos generales y controles de seguridad son válidos para solicitudes de DirectLink: nuevas solicitudes de pedidos, solicitudes de mantenimiento y consultas directas.

1.1 Usuario API

Para realizar solicitudes con DirectLink, se requiere un usuario de interfaz de programación de aplicaciones (API, Application Program Interface).

En general, se trata de un usuario diseñado de forma específica para que la aplicación lo utilice para realizar solicitudes automáticas a la plataforma de pago.

Puede crear un usuario API en su cuenta de Ingenico ePayments a través de "Configuración" > "Usuarios". Seleccione "Nuevo usuario" y complete los campos necesarios.

Para convertir al nuevo usuario en un usuario API, asegúrese de habilitar la casilla "Usuario Especial para el API (sin acceso a admin.)".

Creación de un usuario API

Aunque un usuario API disponga de diversos perfiles de usuario, recomendamos encarecidamente que configure este usuario con el perfil "Admin" (Administración).
Si desea limitar los derechos para el mantenimiento de transacciones (reembolsos, cancelaciones, etc.), puede seguir cambiando el perfil de usuario a, por ejemplo, "Codificador".

Si no está seguro, es recomendable que seleccione el perfil "Admin"; si no, vaya aPerfiles de usuario (Administrador de usuarios) para obtener más información.

La contraseña de un usuario API no tiene que cambiarse de forma regular. Es más cómodo cuando la contraseña debe modificarse en su aplicación. No obstante, recomendamos que cambie la contraseña de vez en cuando.

Si desea más información sobre tipos de usuario y cómo cambiar la contraseña del usuario API, vaya a Tipos de usuario (Administrador de usuarios).

1.2 Formulario de solicitud

Para nuevas solicitudes de pedido, solicitudes de mantenimiento y consultas directas, debe enviar las solicitudes con determinados parámetros a las URL específicas. Los parámetros de nuevo pedido/mantenimiento/consulta deben enviarse en una solicitud POST de la siguiente forma:

PSPID=value1&USERID=value2&PSWD=value3&…

El tipo/subtipo que indica el tipo de medio en el campo Content-Type entity-header de la solicitud POST debe ser "application/x-www-form-urlencoded".

DirectLink funciona en modo “una solicitud-una respuesta”. Cada pago se procesa de forma individual. Nuestro sistema gestiona las solicitudes de transacción individuales a través de DirectLink y puede funcionar de forma sincrónica. (donde está opción es compatible desde un punto de vista técnico). Por ejemplo, esperamos la respuesta del banco antes de devolver una respuesta XML para la solicitud.

1.3 Seguridad

Cuando recibimos una solicitud en nuestros servidores, comprobamos el nivel de cifrado y la dirección IP desde la que se envió la solicitud.

1.3.1 Cifrado

DirectLink se basa en un protocolo sólido de comunicación segura. DirectLink El API de lote es un conjunto de instrucciones enviadas con solicitudes HTTPS POST estándar. Permitimos a los comerciantes que se pongan en contacto con nosotros solo mediante el modo https seguro.
No es necesario un certificado TLS de cliente.

1.3.2 Dirección IP

Con cada solicitud, nuestro sistema comprueba la dirección IP en la que se originó la solicitud para garantizar que las solicitudes se están enviando desde el servidor del comerciante. En el campo Dirección IP de la sección "Comprobaciones de DirectLink" de la pestaña "Verificación de datos y origen" de la página Información técnica de la cuenta, debe especificar la dirección o las direcciones IP o el rango o rangos IP de los servidores que envíen sus solicitudes.

Si la dirección IP de origen no se ha declarado en el campo de dirección IP correspondiente, recibirá el mensaje de error “pedido desconocido/1/i”. La dirección IP desde la que se envió la solicitud también aparecerá en el mensaje de error.

1.3.3 Firma SHA

La firma SHA se basa en el principio del servidor del comerciante que genera una cadena de caracteres única para cada pedido, generando un hash con algoritmos SHA-1, SHA-256 o SHA-512. El resultado de este hash se nos envía más adelante en su solicitud de pedido. Nuestro sistema reconstruye esta firma para comprobar la integridad de los datos del pedido que se nos han enviado en la solicitud.

Vaya a Firma SHA-IN (documentación de Ingenico ePayments e-Commerce). El principio es el mismo en modo e-Commerce y DirectLink.

Para DirectLink, la frase de contraseña SHA-IN debe configurarse en la sección "Comprobaciones de DirectLink" en la pestaña "Verificación de datos y origen" de su página Información técnica.

1.4 Análisis de respuesta

Devolveremos una respuesta XML a su solicitud. Asegúrese de que sus sistemas analizan esta respuesta XML con la mayor tolerancia posible para evitar problemas en el futuro. Por ejemplo, evitar nombres de atributos que distinguen mayúsculas de minúsculas, no formular un orden específico para los atributos devueltos en respuestas, garantizar que los nuevos atributos de la respuesta no causen problemas, etc.

2 Solicitud de nuevo pedido

2.1 URL de solicitud

  • La URL de solicitud en el entorno de PRUEBA es https://ogone.test.v-psp.com/ncol/test/orderdirect.asp.
  • La URL de solicitud en el entorno de PRODUCCIÓN es https://secure.ogone.com/ncol/prod/orderdirect.asp.

Cambiar "test" a "prod"

Sustituya “test” por “prod” en la URL de solicitud cuando cambie a la cuenta de producción. Si olvida cambiar la URL de solicitud una vez que inicia la producción con pedidos reales, las transacciones se enviarán al entorno de prueba y no serán procesadas por las entidades adquirientes/los bancos, por lo que no recibirá el pago.

2.2 Parámetros de solicitud

2.3 Página de prueba

Nuestra página de prueba para enviar solicitudes de pedido en DirectLink está disponible aquí: https://ogone.test.v-psp.com/ncol/test/testodl.asp.

2.4 Excluding specific payment methods

If there are payment methods you don't want a customer to be able to pay with, you can use a parameter to do so.
This is particularly useful for sub-brands, when you want to accept a brand (e.g. MasterCard) but not one of its sub-brands (e.g. Maestro).

The parameter is the following:

Field Usage
EXCLPMLIST
List of payment methods and/or credit card brands that should NOT be used, separated by a “;” (semicolon).

If a customer tries paying with a card linked to a payment method and/or (sub)brand you've excluded using the EXCLPMLIST parameter, the error message “Card number incorrect or incompatible” will be returned with the NCERRORPLUS return field.


2.5 Solicitud de pedido mediante 3-D Secure

Nuestro sistema admite el uso de 3-D Secure con DirectLink.

Importante

  • Si desea utilizar 3-D Secure con DirectLink, es necesario que tenga la opción D3D activada en su cuenta.
  • Algunos bancos adquirentes requieren el uso de 3-D Secure. Consulte con su entidad adquirente si este es su caso.

2.6 Dividir tarjetas de crédito/débito

La funcionalidad para dividir VISA y MasterCard en un método de pago de débito y de crédito le permite ofrecérselo a sus clientes como dos métodos de pago distintos (p. ej. VISA Débito y VISA Crédito) o puede decidir aceptar solo una de las dos marcas divididas.

Para utilizar la división de tarjetas de crédito y débito a través de DirectLink, tiene que incluir el parámetro CREDITDEBIT en los campos ocultos que envía a la página orderdirect.asp (y por tanto también se incluyen en el cálculo de SHA-IN).

Campo Formato
CREDITDEBIT "C": tarjeta de crédito
"D": tarjeta de débito

Error relacionado: Cuando el comprador selecciona el método de tarjeta de crédito, pero introduce a continuación un número de tarjeta de crédito, se devuelve un código de error: ‘Se ha elegido una marca/método de pago incorrecto’.

Si el pago se ha procesado de forma correcta con el parámetro CREDITDEBIT, se devolverá el mismo parámetro en la respuesta XML o podrá solicitarse con una consulta directa. No obstante, mientras que los valores enviados sean C o D, los valores devueltos son "CREDIT" o "DEBIT".

También encontrará estos valores devueltos en la descripción general de la transacción a través de "Ver transacciones" e "Historial financiero", así como en informes que puede descargar más adelante.

Configuración en su cuenta

La funcionalidad de división también se puede activar y configurar según el método de pago en su cuenta de Ingenico ePayments. Acceda a Dividir tarjetas de crédito/débito para obtener más información.

2.7 Procesamiento de transacciones con credenciales guardadas

La transacción de credencial en archivo (COF) utiliza los detalles de la tarjeta que ya están almacenados por los comerciantes para procesar el pago. Antes de iniciar una transacción de credencial en archivo (COF), el titular de la tarjeta primero deberá autorizar al comerciante a almacenar los detalles de la tarjeta. La transacción de credencial en archivo (COF) se aplica principalmente a los pagos recurrentes y establece si es el titular de la tarjeta o el comerciante quien inicia el pago.

Hay dos tipos de transacciones de credenciales en archivo (COF): transacción iniciada por el titular de la tarjeta (CIT) o transacción iniciada por el comerciante (MIT). La transacción iniciada por el titular de la tarjeta (CIT) siempre deberá realizarse antes de la transacción iniciada por el comerciante (MIT).

Una transacción iniciada por el titular de la tarjeta (CIT) es una transacción en la que el titular de la tarjeta participa en la transacción y autentica personalmente la transacción mediante una firma, un dispositivo 3D-Secure o la presentación de documentos identificativos.

Ejemplo de una transacción iniciada por el titular de la tarjeta (CIT):

El titular de una tarjeta compra un billete de tren en línea y realiza un pago. Realiza el pago con su tarjeta de crédito y se le pide que autentique y autorice el pago. Al mismo tiempo, se pregunta al titular de la tarjeta si desea guardar la información de la tarjeta de crédito relacionada con este pago. Si el titular de la tarjeta está de acuerdo, esta información se puede reutilizar en futuras transacciones iniciadas por el comerciante.

Una transacción iniciada por el comerciante (MIT) es una transacción iniciada por un comerciante que supervisa una transacción iniciada por el titular de la tarjeta (CIT) y por un pedido permanente previamente acordado de bienes y servicios comprados por el titular de la tarjeta. El titular de la tarjeta no tiene por qué estar involucrado en la transacción.

Ejemplo de una transacción iniciada por un comerciante (MIT):

Un comerciante puede iniciar automáticamente una transacción para cumplir con el pago del titular de la tarjeta en una suscripción mensual a una revista.

De acuerdo con las regulaciones establecidas por Visa y MasterCard para la transacción de credencial en archivo (COF), se deben enviar nuevos parámetros para determinar la transacción COF.

Esto le afecta si:

  • Utiliza un alias
  • Planea iniciar transacciones recurrentes (programadas o no) después de iniciar por primera vez una transacción iniciada por el titular de la tarjeta (CIT)

Acción necesaria:

De forma predeterminada, estos parámetros se utilizan en una transacción de DirectLink Server-to-Server:

Valores de parámetros COF_INITIATOR-COF_TRANSACTION-COF_SCHEDULE

Descripción

CIT-FIRST-UNSCHED
Se aplica cuando se utiliza o se crea un alias
CIT-FIRST-SCHED

Se aplica a un pago/suscripción programados

MIT-SUBSEQ-UNSCHED
Se aplica a pagos recurrentes
MIT-SUBSEQ-SCHED
Se aplica a pagos de cuotas

Los valores predeterminados se marcan si no se añade ningún parámetro. Sin embargo, si desea cambiarlos, puede sobrescribir estos valores predeterminados enviando los nuevos parámetros. No olvide recalcular también la firma SHA (haga clic aquí para obtener más información sobre la firma SHA.)

Parámetros

Valores

Descriptíon

COF_INITIATOR CIT Transacción iniciada por el titular de la tarjetar
MIT Transacción iniciada por un comerciante
COF_SCHEDULE
SCHED Transacción programada
UNSCHED Transacción no programada
COF_TRANSACTION
FIRST Primera serie de transacciones

SUBSEQ

Siguientes series de transacciones

COF_RECURRING_EXPIRY Fecha YYYYMMDD (por ejemplo: 20190914)
Fecha de fin: fecha del último pago programado de une serie
COF_RECURRING_FREQUENCY
numérico entre 2 y 4 digitos (por ejemplo: 31, 031 o 0031)
Días entre pagos de una serie.

3 Respuesta de pedido

Nuestro servidor devuelve una respuesta XML a la solicitud:

Ejemplo de una respuesta XML a una solicitud de pedido

<?xml version=”1.0”?>
<ncresponse orderID=”99999” PAYID=”1111111” NCSTATUS=”0” NCERROR=”” NCERRORPLUS=”” ACCEPTANCE=”12345” STATUS=”5” ECI=”7” amount="125" currency="EUR" PM="CreditCard" BRAND="VISA"/>

La siguiente tabla contiene una lista de los atributos de etiqueta ncresponse:

Campo Descripción
ACCEPTANCE Código de aceptación devuelto por la entidad adquiriente.
amount Importe del pedido (sin multiplicar por 100).
BRAND Marca de la tarjeta o información similar para otros métodos de pago.
currency Divisa del pedido.
ECI Indicador de comercio electrónico.
NCERROR Código de error.
NCERRORPLUS Explicación del código de error.
NCSTATUS Primer dígito de NCERROR.
orderID Su referencia de pedido.
PAYID Referencia de pago en nuestro sistema.
PM Método de pago.
STATUS Estado de la transacción. (Posibles estados)

La lista de atributos puede ser más larga para comerciantes que tengan activadas determinadas opciones (por ejemplo, la Detección de fraude) en sus cuentas. Consulte la documentación de la opción correspondiente para obtener más información acerca de los atributos de respuesta adicionales vinculados a la opción.

3.1 Solicitud duplicada

Si su solicitud se procesa para un orderID ya existente (y correctamente procesado) nuestra respuesta XML contendrá el PAYID correspondiente al orderID existente, la aceptación (ACCEPTANCE) que le haya dado la entidad adquirente en el procesamiento anterior, STATUS “0” y NCERROR “50001113”.

4 Mantenimiento directo

Una solicitud de mantenimiento directa de su aplicación le permite:

  • Realizar una captura de datos (pago) de un pedido autorizado de forma automática (en lugar de hacerlo manualmente en el área de administración);
  • Cancelar una autorización sobre un pedido;
  • Renovar una autorización de un pedido;
  • Reembolsar un pedido pagado.
Las capturas de datos, las cancelaciones de autorización y las renovaciones de autorización son específicamente para comerciantes que hayan configurado su cuenta o sus solicitudes para realizar la autorización y la captura de datos en dos fases.

4.1 Solicitud de mantenimiento

4.1.1 URL de solicitud

  • La URL de solicitud del entorno de PRUEBA es https://ogone.test.v-psp.com/ncol/test/maintenancedirect.asp.
  • La URL de solicitud del entorno de PRODUCCIÓN es https://secure.ogone.com/ncol/prod/maintenancedirect.asp.

Cambiar "test" a "prod"

Sustituya “test” por “prod” en la URL de solicitud cuando cambie a la cuenta de producción. Si olvida cambiar la URL de solicitud una vez que empiece a trabajar con pedidos reales, las transacciones de mantenimiento se enviarán al entorno de prueba y no a las entidades adquirientes/los bancos.

4.1.2 Parámetros de solicitud

La siguiente tabla contiene los parámetros de solicitud obligatorios para realizar una operación de mantenimiento:

Campo Descripción
AMOUNT
Importe del pedido multiplicado por 100.

Sólo es necesario cuando el importe del mantenimiento difiere del importe de la autorización original. No obstante, recomendamos su uso en todos los casos.

Nuestro sistema comprobará que el importe de la transacción de mantenimiento no sea más alto que el importe de autorización/pago.
OPERATION

Valores posibles:

  • REN: renovación de autorización, si la autorización original ya no es válida.
  • DEL: eliminar autorización, dejando la transacción abierta para más operaciones de mantenimiento potenciales.
  • DES: eliminar autorización, cerrando la transacción después de esta operación.
  • SAL: captura de datos parcial (pago), dejando la transacción abierta para otra captura de datos potencial.
  • SAS: captura (final) de datos parcial o completa (pago), cerrando la transacción (para capturas de datos adicionales) después de esta captura de datos.
  • RFD: reembolso parcial (de un pedido pagado), dejando la transacción abierta para otro reembolso potencial.
  • RFS: reembolso (final) parcial o completo (para un pedido pagado), cerrando la transacción después de este reembolso.

Tenga en cuenta que, con DEL y DES, no todas las entidades adquirentes admiten la eliminación de una autorización. Si la entidad adquirente no admite DEL/DES, simularemos en cualquier caso la eliminación de la autorización en el área de administración.

ORDERID Puede enviar el PAYID o el orderID para identificar el pedido original. Recomendamos el uso del PAYID.
PAYID
PSPID El PSPID de su cuenta.
PSWD Contraseña del usuario API
SHASIGN Firma (cadena con hash) para autenticar los datos (consulte Firma SHA-IN).
USERID Su usuario API

4.1.3 Página de prueba

Puede probar las solicitudes de mantenimiento directas aquí: https://ogone.test.v-psp.com/ncol/test/testdm.asp

4.2 Respuesta de mantenimiento

Nuestro servidor devuelve una respuesta XML a la solicitud:

Ejemplo de una respuesta XML a una solicitud de mantenimiento directa
<?xml version=”1.0”?>
<ncresponse orderID=”99999” PAYID=”1111111” PAYIDSUB=”3” NCSTATUS=”0” NCERROR=”” NCERRORPLUS=”” ACCEPTANCE=”12345” STATUS="91" amount="125" currency="EUR"/>

La siguiente tabla contiene una lista de los atributos de etiqueta ncresponse:

Campo Descripción
ACCEPTANCE Código de aceptación devuelto por la entidad adquiriente
AMOUNT Importe del pedido (sin multiplicar por 100)
CURRENCY Divisa del pedido
NCERROR Código de error
NCERRORPLUS Explicación del código de error
NCSTATUS Primer dígito de NCERROR
ORDERID Su referencia de pedido
PAYID Referencia de pago en nuestro sistema
PAYIDSUB El ID de nivel de historial de la operación de mantenimiento del PAYID
STATUS Estado de la transacción (Posibles estados)

Los atributos de etiqueta ncresponse estándar son los mismos que los de la respuesta XML a un nuevo pedido, salvo el atributo extra PAYIDSUB.

4.3 Solicitud duplicada

Si se solicita mantenimiento dos veces para el mismo pedido, el segundo se rechazará, en teoría, con un error “50001127” (este pedido no está autorizado), porque la transacción correcta inicial habrá cambiado el estado del pedido.

5 Consulta directa

Una solicitud de consulta directa de su aplicación le permite consultar el estado de un pedido de forma automática (a diferencia de manualmente en el área de administración). Solo puede consultar un pago a la vez y solo recibirá un importe limitado de información sobre el pedido.

Si necesita más detalles sobre el pedido, puede buscar la transacción en el área de administración o realizar una descarga de archivo manual o automática (consulte Consultar sus transacciones y Fichero de Lote).

5.1 Solicitud de consulta

5.1.1 URL de solicitud

  • La URL de solicitud del entorno de PRUEBA es https://ogone.test.v-psp.com/ncol/test/querydirect.asp
  • La URL de solicitud del entorno de PRODUCCIÓN es https://secure.ogone.com/ncol/prod/querydirect.asp

Cambiar "test" a "prod"

Sustituya “test” por “prod” en la URL de solicitud cuando cambie a la cuenta de producción.

5.1.2 Parámetros de solicitud

La siguiente tabla contiene los parámetros de solicitud obligatorios para realizar una consulta directa:

Campo
Descripción
ORDERID

Puede enviar el PAYID o el ORDERID para identificar el pedido original. Recomendamos el uso del PAYID.

PAYID
PAYIDSUB
Puede indicar el ID de nivel de historial si utiliza el PAYID para identificar el pedido original (opcional).
PSPID
El PSPID de su cuenta.
PSWD
Contraseña del usuario API
USERID
Su usuario API

5.1.3 Página de prueba

Puede probar las solicitudes de consulta directa aquí: https://ogone.test.v-psp.com/ncol/test/testdq.asp.

5.2 Respuesta de consulta

Nuestro servidor devuelve una respuesta XML a la solicitud:

Ejemplo de una respuesta XML a una consulta directa

<?xml version=”1.0”?>
<ncresponse orderID=”99999” PAYID=”1111111” PAYIDSUB=”3” NCSTATUS=”0” NCERROR=”” NCERRORPLUS=”” ACCEPTANCE=”12345” STATUS="9" ECI=”7” amount="125" currency="EUR" PM="CreditCard" BRAND="VISA" CARDNO="XXXXXXXXXXXX1111" IP="212.33.102.55"/>

La siguiente tabla contiene una lista de los atributos de etiqueta ncresponse:

Campo
Uso
ACCEPTANCE Código de aceptación devuelto por la entidad adquiriente
amount Importe del pedido (sin multiplicar por 100)
BRAND Marca de la tarjeta o información similar para otros métodos de pago
CARDNO El número de tarjeta de crédito enmascarado
currency Divisa del pedido
ECI Indicador de comercio electrónico
IP La dirección IP del cliente, según la haya detectado nuestro sistema en una integración de nivel 3 o haya sido proporcionada por el comerciante en una integración de nivel 2
NCERROR Código de error
NCERRORPLUS Explicación del código de error
NCSTATUS Primer dígito de NCERROR
orderID Su referencia de pedido
PAYID Referencia de pago en nuestro sistema
PAYIDSUB El ID de nivel de historial de la operación de mantenimiento del PAYID
PM Método de pago
STATUS Estado de la transacción

Los atributos de etiqueta ncresponse estándar son idénticos a los de la respuesta XML a un nuevo pedido, salvo los atributos adicionales PAYIDSUB, CARDNO e IP.

La lista de atributos puede ser más larga para comerciantes que tengan activadas determinadas opciones (por ejemplo, la Detección de fraude) en sus cuentas. Consulte la documentación de la opción respectiva para obtener más información acerca de los atributos de respuesta adicionales vinculados a la opción.

5.2.1 Transacciones procesadas con e-Commerce

Si la transacción cuyo estado desea comprobar se ha procesado con e-Commerce, puede que también reciba los siguientes atributos adicionales (siempre que haya enviado estos campos con la transacción original de e-Commerce).

Campo
Descripción
complus*
Un valor que deseaba que le devolviesen
(contenido de paramplus)*
Los parámetros y sus valores que deseaba que le devolviesen

*Consulte Parámetros de respuesta variables en la documentación de e-Commerce.

Ejemplo de una respuesta XML a una consulta directa para una transacción de e-Commerce

<ncresponse orderID=”99999” PAYID=”1111111” PAYIDSUB=”3” NCSTATUS=”0” NCERROR=”” NCERRORPLUS=”” ACCEPTANCE=”12345” STATUS="9" amount="125" currency="EUR" PM="CreditCard" BRAND="VISA" CARDNO="XXXXXXXXXXXX1111" IP="212.33.102.55" COMPLUS="123456789123456789123456789" SessionID="126548354" ShopperID="73541312"/>

5.3 Posibles estados de respuesta

El campo STATUS contendrá el estado de la transacción (consulte Posibles estados).

Solo el siguiente estado está relacionado de forma específica con la propia consulta:

EstadoNCERRORNCSTATUS Descripción
88 La consulta sobre querydirect.asp ha fallado

5.4 Consulta directa como último recurso

Los tiempos de respuesta de una solicitud de transacción de DirectLink suelen ser de unos pocos segundos. No obstante, algunas entidades adquirentes pueden tener tiempos de respuesta más largos.

Si no ha recibido una respuesta de nuestro sistema pasados 30 segundos, puede enviar una solicitud a querydirect.asp, pidiéndole el estado de su transacción más reciente enviada a orderdirect.asp. Si recibe una respuesta inmediata que contenga un estado no final para la transacción, puede que haya problemas por parte de la entidad adquirente.

Si no ha recibido una respuesta a esta solicitud de consulta directa pasados 10 segundos, puede que haya problemas de nuestro lado. Puede repetir esta solicitud a querydirect.asp cada 30 segundos hasta que vea que ha recibido una respuesta en 10 segundos.

Nota
  • Este sistema de comprobación solo podrá detallar problemas por nuestra parte si también hay una comprobación por la suya para verificar que las solicitudes se han emitido correctamente desde los servidores.
  • Un problema por nuestra parte no siempre estará necesariamente causado por el tiempo de inactividad, sino que también podría ser el resultado de tiempos de respuesta lentos debido a, por ejemplo, problemas en la base de datos.
  • Utilice estas comprobaciones de manera juiciosa para evitar colapsar nuestros servidores de solicitudes. En caso contrario, podríamos restringirle el acceso a la página de querydirect.asp.

Importante

Para proteger nuestro sistema de sobrecargas innecesarias, prohibimos las comprobaciones de sistema activado que impliquen enviar falsas transacciones o consultas sistemáticas, así como consultas sistemáticas para obtener respuesta de transacción para cada transacción.

6 Solicitud de aviso de privacidad de Controlador de datos

En función de los artículos 12, 13 y 14 del RGPD, un Controlador de datos tiene la obligación de informar a los clientes finales acerca del procesamiento futuro de sus datos personales. Dicha información debe realizarse de forma específica en función del tipo de datos personales que se introducen para una transacción concreta (p. ej., método de pago seleccionado, controlador/procesador, entidad adquiriente, fraude). El resultado debería estar disponible y visible en el momento de la recopilación de datos y al titular de tarjeta se le debe ofrecer una versión de los mismos que se pueda imprimir y descargar. Según la política del RGPD, tiene que mostrar la información al cliente antes de validar la transacción. Esta información debería mostrarse idealmente en la misma página donde el cliente rellena las credenciales de tarjeta/cuenta.
La solicitud de política de privacidad siguiente le permite recuperar toda la información que tiene que mostrar a sus clientes acerca de nuestros servicios para poder cumplir la normativa del RGPD.

6.1 URL de solicitud

6.1.1 Solicitud de consulta

• La URL de solicitud del entorno de PRUEBA es https://secure.ogone.com/ncol/test/privacy-policy.asp

• La URL de solicitud del entorno de PRODUCCIÓN es https://secure.ogone.com/ncol/prod/privacy-policy.asp
Cambiar "test" a "prod"
Sustituya "test" por "prod" en la URL de solicitud cuando cambie a la cuenta de producción.

6.1.2 Parámetros de solicitud

La tabla siguiente contiene los parámetros de solicitud obligatorios que enviar a su cliente en relación al uso de su información de privacidad:

Campo Formato
Descripción
USERID Cadena
Su usuario API
PSWD Cadena
Su contraseña de usuario API
PSPID
Cadena
El PSPID de su cuenta
BRAND Cadena (p. ej. Visa)

Opcional: Marca de método de pago
Puede enviar este campo varias veces para obtener el resultado de varias marcas a la vez.
• No enviar ninguna marca equivale a enviar todas las marcas activas.

• Las marcas sin formato o con formato erróneo se ignoran.
LANGUAGE ISO 639-1: Two-letter codes (e.g. FR) Opcional: El idioma en el que desea recuperar el texto.
Si no se facilita, el texto se devolverá en el idioma configurado por el comerciante.

6.1.3 Página de prueba

Puede probar las solicitudes de consulta directa aquí: https://secure.ogone.com/ncol/test/privacy-policy.asp

6.2 Respuesta de consulta

A continuación se muestra una lista de elementos XML y los ejemplos de respuestas XML devueltas para distintos resultados.

Nombre Formato Descripción
Response
Complejo
Nodo raíz, siempre presente
Response.Status
Cadena, valores posibles: Success, SuccessWithWarnings, Error
Siempre presente
Response.Body
Complejo
Presente solo cuando Response.Status = Success o SuccessWithWarnings
Response.Body.Html
Cadena / html
Vacío si Response.Status = SuccessWithWarnings y Response.Warnings.Warning.Code = NoContent
Response.Errors
Complejo
Presente solo cuando Response.Status = Error
Response.Errors.Error
Complejo
Puede ocurrir varias veces dentro de un nodo <Errors>
Response.Warnings
Complejo
Presente solo cuando Response.Status = SuccessWithWarnings o Error
Response.Warnings.Warning Complex
Ocurre varias veces dentro de un nodo <Warnings>
Response.Errors.Error.Code
Response.Warnings.Warning.Code

Cadena, valores posibles:
• Dentro de un nodo <Error>: Unauthorized, InternalServerError
• Dentro de un nodo <Warning>: NoContent

Siempre presente en un nodo <Error> o <Warning>
Response.Errors.Error.Message
Response.Warnings.Warning.Message
Cadena
Opcional

Si se enfrenta a Response.Status=Error, consulte Response.Errors.Error para corregirlo.
Los siguientes son dos ejemplos de éxito:

1. Ejemplo de una respuesta XML para éxito con advertencias. Se devuelve si no se tiene que revelar al cliente información de privacidad.

<?xml version="1.0" encoding="utf-8"?>
<Response>
<Status>SuccessWithWarnings</Status>
<Warnings>
<Warning>
<Code>NoContent</Code>
</Warning>
</Warnings>
<Body>
<Html/>
</Body>
</Response>

2. Ejemplo de una respuesta XML para éxito con contenido. El ejemplo muestra una visualización de dos secciones.

<?xml version="1.0" encoding="utf-8"?>
<Response>
<Status>Success</Status>
<Body>
<Html><![CDATA[<ul><li><h2>Title 1</h2><p>Content 1</p></li><li> <h2>Title 2 (VISA, American Express)</h2><p>Content 2</p></li></ul>]]></Html>
</Body>
</Response>

7 Excepciones de método de pago

Para determinados métodos de pago, los valores de parámetro difieren de los de tarjeta de crédito estándar.

7.1 Direct Debits

7.1.1 Domiciliaciones AT

La siguiente tabla contiene los valores de parámetro específicos que permiten la transmisión de transacciones de Domiciliaciones AT a través de DirectLink.

Formato: AN= Alfanumérico/N=Numérico, cantidad máxima de caracteres permitida
Campo Descripción Formato/Valor
CARDNO

Número de cuenta bancaria

AN, 21

Formato: XXXXXXXXXXXBLZYYYYY

XXXXXXXXXXX: número de cuenta, numérico, 11 dígitos.
YYYYY: Código de banco (Bankleitzahl), 5 dígitos.
CN Nombre del titular de la cuenta bancaria AN, 35
ED Fecha de caducidad
„99/99“ o „9999“
OPERATION

Código de operación (acción que debe realizarse)

A, 3

Valores posibles:

  • RES: autorización
  • SAL/SAS: dinero de débito de la cuenta bancaria
  • RFD/RFS: reembolsar dinero (*)
OWNERADDRESS Dirección del titular de la cuenta AN, 50
OWNERTOWN Ciudad/población del titular de la cuenta AN, 40
OWNERZIP Código postal del titular de la cuenta AN, 10
PM Método de pago AN, 25

“Direct Debits AT”

(*Si la opción Reembolso está disponible y activa, y Reembolsos de DTAUS está disponible)

7.1.2 Domiciliaciones DE (ELV)

La siguiente tabla contiene los valores de parámetro específicos, que permiten la transmisión de transacciones de ELV a través de DirectLink. (no Wirecard/Billpay)

Formato: AN= Alfanumérico/N=Numérico, cantidad máxima de caracteres permitida
Campo Descripción Formato/Valor Obligatorio
CARDNO Número de cuenta bancaria

IBAN: 22 caracteres alfanuméricos

O

Número de cuenta bancaria + BLZ. Formato: XXXXXXXXXBLZYYYYYYYY
XXXXXXXXXX: número de cuenta, numérico, de 1 a 10 dígitos.
YYYYYYYY: Código de banco (Bankleitzahl), 8 dígitos.

CN Nombre del titular de la cuenta bancaria AN, 35
ED Fecha de caducidad „99/99“ o „9999“
MANDATEID Referencia de autorización unívoca.
Telego:
Si no se proporciona, la plataforma usará el ORDERID o PAYID
Nota: Si no se proporciona, Easycash generará un valor.

Telego: AN, 35/Conjunto de caracteres: “A-Z a-z 0-9 espacio /-?:().,'+”)
Si no se proporciona, la plataforma tomará el ORDERID o PAYID

Easycash: Formato: AN, 27/Conjunto de caracteres: “A-Z a-z 0-9 espacio /-?:().,'+”)
Nota: Si no se proporciona, Easycash generará un valor.

No
OPERATION Código de operación (acción que debe realizarse)

A, 3

Valores posibles:

  • RES: autorización
  • SAL/SAS: dinero de débito de la cuenta bancaria
  • RFD/RFS: reembolsar dinero (*)
No
OWNERADDRESS Dirección postal y número del titular de la cuenta AN, 50
OWNERTOWN Ciudad/población del titular de la cuenta AN, 40
OWNERZIP Código postal del titular de la cuenta AN, 10
PM Método de pago

AN, 25

"Domiciliaciones DE”



Nota: Estos campos se pueden devolver en la respuesta XML de DirectLink y deben incluirse en el cálculo SHA-IN (opcionalmente, también en SHA-OUT).

(*Si la opción Reembolso está disponible y activa, y Reembolsos de DTAUS está disponible)

7.1.3 Domiciliaciones NL

La siguiente tabla contiene los valores de parámetro específicos que permiten la transmisión de transacciones de Domiciliaciones NL a través de DirectLink.

Formato: AN= Alfanumérico/N=Numérico, cantidad máxima de caracteres permitida
Campo Descripción Formato/Valor
CARDNO Número de cuenta bancaria Número de cuenta holandés normal: máx. 10 caracteres alfanuméricos (si es inferior, complete con ceros a la izquierda).

O

Número de cuenta IBAN: máx. 35 caracteres alfanuméricos (SEPA)

CN Nombre del titular de la cuenta bancaria AN, 35
ED Fecha de caducidad „99/99“ o „9999“
OPERATION

Código de operación (acción que debe realizarse)

A, 3

Valores posibles:

  • SAL o SAS: dinero de débito de la cuenta bancaria
  • RFD o RFS: dinero de crédito a la cuenta bancaria (reembolso)
OWNERTOWN Ciudad del titular de la cuenta bancaria AN, 40
PM Método de pago

AN, 25

“Domiciliaciones NL”

Solo relevante para transacciones SEPA (*) :
BIC Código identificador de banco AN, 11
MANDATEID

Referencia de autorización unívoca.

Nota: Si no se proporciona, se usará el ORDERID.

AN, 35

No se permiten espacios; no puede empezar ni terminar con una barra inclinada "/" ni contener dos barras consecutivas.

SEQUENCETYPE

El tipo de transacción de Domiciliaciones

Nota: Si no se proporciona, las transacciones se considerarán de “una sola vez” y se usará el valor "OOFF".

Posibles valores para indicar el tipo de transacción de Domiciliaciones (AN, 4):
  • "FRST": Primer grupo de una serie de instrucciones de Domiciliaciones
  • "RCUR": Instrucciones de Domiciliaciones en las que se utiliza la autorización del deudor para transacciones normales de este tipo iniciadas por el acreedor
  • "FNAL": Grupo final de una serie de instrucciones de Domiciliaciones (posteriormente no se puede volver a utilizar el mismo MandateID)
  • "OOFF": orden de adeudo directo en la que se utiliza la autorización del deudor para iniciar una única transacción de domiciliación
SIGNDATE

Fecha en la que el comprador firmó la autorización.

Nota: Si no se proporciona, se usará la fecha de la transacción.

AAAAMMDD

(*SEPA: Single Euro Payments Area o Zona Única de Pagos en Euros)

Nota: Estos campos se pueden devolver en la respuesta XML de DirectLink y deben incluirse en el cálculo SHA-IN (y, opcionalmente, SHA-OUT).

Para determinados métodos de pago (tarjeta que no sea de crédito), no puede enviar nuevas transacciones a través de DirectLink, pero puede enviar determinadas operaciones de mantenimiento a través de DirectLink. Es el caso de la tarjeta PostFinance, PostFinance E-finance, compra mediante PayPal Express y TUNZ. Cuando se envían operaciones de mantenimiento, PM/BRAND/CARDNO/ED no son campos necesarios, así que, para estos métodos de pago, no deben enviarse valores específicos.

8 3-D Secure v1.0

8.1 Introducción

El protocolo 3-D permite la identificación del titular de la tarjeta durante el proceso de compra. El titular de la tarjeta debe estar conectado a Internet durante el proceso de identificación. Por tanto, 3-D Secure no funciona para centros de llamadas o pagos periódicos.

Visa ha implementado el protocolo 3-D Secure con el nombre Verified By Visa, MasterCard con el nombre SecureCode, JCB con el nombre J-Secure y American Express con el nombre SafeKey.

El principio de la integración de DirectLink con 3-D Secure es iniciar un pago en modo DirectLink y finalizarlo en modo e-Commerce si se solicita la autenticación del titular.

Este documento describe la integración del protocolo 3-D Secure en DirectLink. Para obtener más información sobre DirectLink o e-Commerce, consulte la documentación de DirectLink o e-Commerce.

El flujo de transacciones implica los siguientes pasos:

  1. Envíenos una solicitud de DirectLink para la transacción con el número de parámetros adicionales (véase Parámetros de solicitud extra).
  2. Nuestro sistema recibe el número de tarjeta en su solicitud y comprueba en línea si la tarjeta está registrada en el directorio VISA/MasterCard/JCB/AmEx (registrada significa que la identificación es posible para el número de tarjeta; por ejemplo, es una tarjeta 3-D Secure).
  3. Si el titular de la tarjeta está registrado, la respuesta a la solicitud de DirectLink contendrá un estado de pago específico y código html que se devolverá al cliente para iniciar el proceso de identificación (véase Campos devueltos adicionales). El bloque de código html iniciará automáticamente el proceso de identificación entre el titular de la tarjeta (cliente) y su banco emisor.
  4. El titular de la tarjeta se identifica a sí mismo en la página del banco emisor.
  5. Nuestro sistema recibe la respuesta de identificación del emisor.
  6. Si la identificación ha sido correcta, nuestro sistema enviará la transacción financiera real a la entidad adquirente.
  7. Recibirá el resultado de la identificación global y el proceso de autorización en línea a través de los canales de respuesta del modo e-Commerce.

Comentarios:

  • La aplicación de la transferencia de responsabilidad dependerá del contrato de su entidad adquirente. Por tanto, le recomendamos consultar los términos y condiciones con su entidad adquirente.
  • Si el titular de la tarjeta no está registrado (en el paso 3), recibirá la respuesta XML de DirectLink estándar que contiene el resultado del proceso de autorización en línea.
  • Para recibir los códigos de estado/error de pago exactos (en el paso 7), deberá implementar la respuesta posventa en línea o sin conexión, tal como se describe en la documentación de e-Commerce.

8.2.1 Parámetros de solicitud extra

Aparte de los parámetros de DirectLink estándar, también es posible que tenga que enviar la siguiente información:

Campo Descripción
FLAG3D

Valor fijo: ‘Y’

Indica a nuestro sistema que lleve a cabo una identificación 3-D Secure si es necesario.

HTTP_ACCEPT El campo Aceptar de la cabecera de la solicitud en el navegador del titular de la tarjeta se utiliza para especificar determinados tipos de medios aceptables para la respuesta. El emisor utiliza este valor para comprobar si el navegador del titular de la tarjeta es compatible con el sistema de identificación del emisor. Por ejemplo:
Aceptar: */*
HTTP_USER_AGENT El campo Agente del usuario de la cabecera de la solicitud en el navegador del titular de la tarjeta contiene información sobre el agente del usuario que originó la solicitud. El emisor utiliza este valor para comprobar si el navegador del titular de la tarjeta es compatible con el sistema de identificación del emisor. Por ejemplo: Agente del usuario: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
WIN3DS Forma de mostrar la página de identificación al cliente. Valores posibles:
  • MAINW: muestra la página de identificación en la ventana principal (valor predeterminado).
  • POPUP: muestra la página de identificación en una ventana emergente y vuelve a la ventana principal al final.
  • POPIX: muestra la página de identificación en una ventana emergente y permanece en la ventana emergente.
ACCEPTURL URL de la página web para mostrar al cliente cuando se autoriza el pago. (o se espera que se autorice).
DECLINEURL URL al que se redirecciona al cliente si se ha alcanzado el máximo número de intentos de autorización fallidos (10 de forma predeterminada, pero que puede cambiar en la página Información técnica, pestaña "Parámetros de transacción globales", sección "Reintento de pago").
EXCEPTIONURL URL de la página web para mostrar al cliente cuando el resultado del pago es dudoso.
PARAMPLUS Campo para enviar parámetros varios y los valores que desea que se devuelvan en la solicitud de posventa o en el redireccionamiento final.
COMPLUS Campo para enviar un valor que desea que se devuelva en la solicitud de postventa o en la respuesta.
LANGUAGE Idioma del cliente, por ejemplo: “en_US”
Opcional
TP Para cambiar el diseño de la página "order_A3DS", puede enviar un nombre/url de plantilla con este parámetro. (vaya a e-Commerce: Plantilla dinámica).

Si desea más información, vaya a Respuesta de transacción.

8.2.2 Campos devueltos adicionales

Si el titular no está registrado, se devolverá la respuesta de DirectLink normal. Si el titular está registrado, se devolverán los siguientes campos (adicionales):

Campo Descripción
STATUS
Nuevo valor: “46” (esperando identificación)
HTML_ANSWER

Se puede añadir código HTML codificado con BASE64 en la página HTML devuelta al cliente.

Esta etiqueta se añade como elemento secundario de la etiqueta global XML <ncresponse>. El campo HTML_Answer contiene código HTML que añadirse a la página HTML devuelta al navegador del cliente.

Este código cargará automáticamente la página de identificación del banco emisor en una ventana emergente en la ventana principal, dependiendo del valor del parámetro WIN3DS.

Para evitar cualquier interferencia entre las etiquetas HTML incluidas en el contenido de la etiqueta HTML_ANSWER XML con el resto del XML devuelto como respuesta a la solicitud de DirectLink, el contenido de HTML_ANSWER es codificado mediante BASE64 por nuestro sistema antes de enviar la respuesta. En consecuencia, se debe descodificar mediante BASE64 antes de incluirlo en la página HTML enviada al titular de la tarjeta.

8.2.3 Comentarios

Tarjetas de prueba

Puede usar las siguientes tarjetas de prueba para simular una tarjeta registrada 3-D Secure en nuestro entorno de prueba:

Marca Número de tarjeta Fecha de caducidad Contraseña
VISA 4000000000000002 Cualquier fecha del futuro 11111
MasterCard 5300000000000006 Cualquier fecha del futuro 11111
American Express 371449635311004 Cualquier fecha del futuro 11111
Identificación incorrecta

Si una transacción está bloqueada debido a una identificación incorrecta, el resultado de la transacción será:

STATUS = 0

NCSTATUS = 5

NCERROR = 40001134

9 3-D Secure v2.1

9.1 Introducción

En 2013, la Comisión Europea publicó una propuesta para elaborar una versión revisada de la Directiva sobre servicios de pago, conocida como PSD2, para simplificar el procesamiento de pagos y crear reglas y reglamentos para los servicios de pago en la UE, lo que desencadenó la necesidad de desarrollar una versión nueva de 3-D Secure, denominada v2.1.

El cambio más importante es que se le solicita que, en calidad de comerciante, comparta más datos: los emisores tienen un gran interés en que los puntos de datos mejoren la precisión en las decisiones, lo que en última instancia conducirá a un escenario libre de problemas, pero son ustedes, los comerciantes, los que están en primera línea en lo que se refiere a la captura de datos. El enfoque de 3DS v2 sobre la evaluación de riesgos es más efectivo, pero le obliga a cambiar todo el ecosistema para que pueda hacer llegar los datos al emisor.

Los principales esquemas de las tarjetas de pago han actualizado sus logotipos 3DS con la introducción de esta nueva guía.
Asegúrese de implementar estos nuevos logotipos en la creación de su página de pago (Visa / Mastercard / JCB /… ).

9.2 Flujo de transacciones 3-D a través de DirectLink

El flujo de la transacción implica los pasos siguientes:

1. Nos envía una solicitud de DirectLink para la transacción que contiene una serie de parámetros adicionales.

Estos parámetros se pueden agrupar en tres conjuntos:

a. Los parámetros obligatorios que deben capturarse en la página de pago donde el titular de la tarjeta está ingresando los detalles de la tarjeta.

ParámetrosDescripciónFormatoObligatorio
browserAcceptHeader

Contenido exacto de los encabezados HTTP Accept, tal como se envían al comerciante desde el navegador del titular de la tarjeta. *

Tipo de datos: cadena Longitud: variable, máx. 2.048 caracteres
Valor aceptado:
Si la longitud total del encabezado
Accept enviado por el navegador
supera los 2.048 caracteres, el
servidor 3DS truncará el excedente.
browserColorDepth Valor que representa la profundidad de bits de la paleta de colores para visualizar imágenes, en bits por píxel. La proporciona el navegador del titular de la tarjeta mediante la propiedad de profundidad de color de pantalla. Tipo de datos: cadena
Valores aceptados:
1 = 1 bit
4 = 4 bits
8 = 8 bits
15 = 15 bits
16 = 16 bits
24 = 24 bits
32 = 32 bits
48 = 48 bits
browserJavaEnabled Valor booleano que representa la capacidad del navegador del titular de la tarjeta para ejecutar Java. El valor es devuelto por la propiedad de Java Enabled del navegador. Tipo de datos: booleano
Valores aceptados:
true
false
browserLanguage Valor que representa el idioma del navegador, tal como se define en IETF BCP47. Lo devuelve la propiedad Language del navegador. Tipo de datos: cadena
Longitud: variable, 1-8 caracteres
browserScreenHeight Altura total de la pantalla del titular de la tarjeta, en píxeles. El valor es devuelto por la propiedad Screen Height. Tipo de datos: Int
entre 0 y 999999
browserScreenWidth Anchura total de la pantalla del titular de la tarjeta, en píxeles. El valor es devuelto por la propiedad Screen Width. Tipo de datos: Int
entre 0 y 999999
browserTimeZone Diferencia horaria entre la hora UTC y la hora local del navegador del titular de la tarjeta, en minutos. Tipo de datos: Int
entre -840 y 720
browserUserAgent Contenido exacto del encabezado HTTP User-Agent. * Tipo de datos: cadena
Longitud: variable, máx. 2.048 caracteres
Nota: si la longitud total del
encabezado User-Agent enviado por
el navegador supera los 2.048
caracteres, el servidor 3DS truncará
el excedente.
CN Nombre del titular de la tarjeta (cliente) Longitud: variable, máx. 35
Se permiten caracteres
especiales, pero se
recomienda evitar el uso de
comillas. La mayoría de los
adquirientes no comprueban
el nombre del cliente, ya que
los nombres a veces se
escriben de múltiples formas

*No tiene que enviar HTTP_ACCEPT y HTTP_USER_AGENT con browserAcceptHeader y browserUserAgent; los rellenaremos con los parámetros del navegador.

Nota: No olvide calcular los parámetros en su firma SHA.

A continuación encontrará un ejemplo de código Javascript para capturar estos parámetros.

<script type="text/javascript" language="javascript">

function createHiddenInput(form, name, value)
{
var input = document.createElement("input");
input.setAttribute("type", "hidden");
input.setAttribute("name", name);
input.setAttribute("value", value);
form.appendChild(input);
}

var myCCForms = document.getElementsByName("MyForm");
if (myCCForms != null && myCCForms.length > 0)
{
var myCCForm = myCCForms[0];
createHiddenInput(myCCForm, "browserColorDepth", screen.colorDepth);
createHiddenInput(myCCForm, "browserJavaEnabled", navigator.javaEnabled());
createHiddenInput(myCCForm, "browserLanguage", navigator.language);
createHiddenInput(myCCForm, "browserScreenHeight", screen.height);
createHiddenInput(myCCForm, "browserScreenWidth", screen.width);
createHiddenInput(myCCForm, "browserTimeZone", new Date().getTimezoneOffset());
}
</script>

b. Parámetros adicionales obligatorios (véase Parámetros de solicitud extra)

c. Parámetros recomendados (lista de parámetros) que, si se envían, tendrán un efecto positivo en la tasa de conversión de las transacciones. De acuerdo con la información que contienen estos parámetros, puede producirse un flujo de autenticación sin problemas, en el que ya no se tenga que autenticar al titular de la tarjeta, por lo que se prevé que la transacción se complete de forma más rápida. Por el contrario, si no se proporciona ninguno de estos parámetros, se llevará a cabo el redireccionamiento relacionado con la autenticación normal.

Aunque estos parámetros son opcionales, los planes de las principales tarjetas de pago recomiendan incluir los siguientes parámetros en la solicitud, ya que de este modo será más probable lograr un flujo sin fricción.

ECOM_BILLTO_POSTAL_CITY
ECOM_BILLTO_POSTAL_COUNTRYCODE
ECOM_BILLTO_POSTAL_STREET_LINE1
ECOM_BILLTO_POSTAL_STREET_LINE2
ECOM_BILLTO_POSTAL_STREET_LINE3
ECOM_BILLTO_POSTAL_POSTALCODE
REMOTE_ADDR
CN
EMAIL

Nuestro sistema recibe el número de tarjeta en su solicitud y comprueba en línea si la tarjeta está registrada en el directorio VISA/MasterCard/JCB/AmEx (registrada significa que la identificación es posible para el número de tarjeta; por ejemplo, es una tarjeta 3-D Secure).

2. De acuerdo con la respuesta del directorio de los sistemas, si el titular de la tarjeta está registrado para 3-D Secure, se prevén dos posibles flujos, en función de si se han proporcionado los parámetros adicionales indicados en el apartado 1.c (Parámetros recomendados-lista de parámetros) anterior:

2.1. Un flujo sin problemas: El titular de la tarjeta no necesita físicamente autenticarse porque la autenticación se realizó en segundo plano sin su aportación. En este caso, el cambio de responsabilidad es del banco emisor.>

2.2. Un flujo con comprobación: Se debe realizar una identificación adicional del titular de la tarjeta.

i. La respuesta a la solicitud de DirectLink contiene un estado de pago específico y un código html que se debe devolver al cliente para iniciar el proceso de identificación (véase Campos de devolución adicionales). El bloque de código html iniciará automáticamente el proceso de identificación entre el (cliente) titular de la tarjeta y el banco emisor.

ii. El titular de la tarjeta se identifica a sí mismo en la página del banco emisor.

iii. Nuestro sistema recibe la respuesta de identificación del emisor.

iv. Si la identificación ha sido correcta, nuestro sistema enviará la transacción financiera real a la entidad adquirente.

3. Recibirá el resultado de la identificación global y el proceso de autorización en línea a través de los canales de respuesta del modo e-Commerce.

9.2.1 Parámetros de solicitud extra

Aparte de los parámetros de DirectLink estándar, también es posible que tenga que enviar la siguiente información:

Campo Descripción
FLAG3D

Valor fijo: ‘Y’

Indica a nuestro sistema que lleve a cabo una identificación 3-D Secure si es necesario.

HTTP_ACCEPT El campo Aceptar de la cabecera de la solicitud en el navegador del titular de la tarjeta se utiliza para especificar determinados tipos de medios aceptables para la respuesta. El emisor utiliza este valor para comprobar si el navegador del titular de la tarjeta es compatible con el sistema de identificación del emisor. *
Por ejemplo:
Aceptar: */*
HTTP_USER_AGENT El campo Agente del usuario de la cabecera de la solicitud en el navegador del titular de la tarjeta contiene información sobre el agente del usuario que originó la solicitud. El emisor utiliza este valor para comprobar si el navegador del titular de la tarjeta es compatible con el sistema de identificación del emisor. *
Por ejemplo: Agente del usuario: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
WIN3DS Forma de mostrar la página de identificación al cliente. Valores posibles:
  • MAINW: muestra la página de identificación en la ventana principal (valor predeterminado).
  • POPUP: muestra la página de identificación en una ventana emergente y vuelve a la ventana principal al final.
  • POPIX: muestra la página de identificación en una ventana emergente y permanece en la ventana emergente.
ACCEPTURL URL de la página web para mostrar al cliente cuando se autoriza el pago. (o se espera que se autorice).
DECLINEURL URL al que se redirecciona al cliente si se ha alcanzado el máximo número de intentos de autorización fallidos (10 de forma predeterminada, pero que puede cambiar en la página Información técnica, pestaña "Parámetros de transacción globales", sección "Reintento de pago").
EXCEPTIONURL URL de la página web para mostrar al cliente cuando el resultado del pago es dudoso.
PARAMPLUS Campo para enviar parámetros varios y los valores que desea que se devuelvan en la solicitud de posventa o en el redireccionamiento final.
COMPLUS Campo para enviar un valor que desea que se devuelva en la solicitud de postventa o en la respuesta.
LANGUAGE Idioma del cliente, por ejemplo: “en_US”
Opcional
TP Para cambiar el diseño de la página "order_A3DS", puede enviar un nombre/url de plantilla con este parámetro. (vaya a e-Commerce: Plantilla dinámica).

*No será necesario enviar HTTP_ACCEPT y HTTP_USER_AGENT si se envían browserAcceptHeader y browserUserAgent.

Si desea más información, vaya a Respuesta de transacción.

9.2.2 Campos devueltos adicionales

Si el titular no está registrado, se devolverá la respuesta de DirectLink normal. Si el titular está registrado, se devolverán los siguientes campos (adicionales):

Campo Descripción
STATUS
Nuevo valor: “46” (esperando identificación)
HTML_ANSWER

Se puede añadir código HTML codificado con BASE64 en la página HTML devuelta al cliente.

Esta etiqueta se añade como elemento secundario de la etiqueta global XML <ncresponse>. El campo HTML_Answer contiene código HTML que añadirse a la página HTML devuelta al navegador del cliente.

Este código cargará automáticamente la página de identificación del banco emisor en una ventana emergente en la ventana principal, dependiendo del valor del parámetro WIN3DS.

Para evitar cualquier interferencia entre las etiquetas HTML incluidas en el contenido de la etiqueta HTML_ANSWER XML con el resto del XML devuelto como respuesta a la solicitud de DirectLink, el contenido de HTML_ANSWER es codificado mediante BASE64 por nuestro sistema antes de enviar la respuesta. En consecuencia, se debe descodificar mediante BASE64 antes de incluirlo en la página HTML enviada al titular de la tarjeta.

9.2.3 3-D Secure v2.1 MasterCard+

Para aumentar al máximo la posibilidad de flujo sin problemas, MasterCard ha desarrollado la extensión específica “MasterCard 2.1+”. Esto significa que es posible enviar tres parámetros adicionales además de los parámetros recomendados.

ParámetroNombreDescripciónFormato
Mpi.merchantFraudRate
Tasa de fraude para comerciantes

La tasa de fraude para comerciantes en la zona EEE (el fraude total de tarjetas del EEE dividido por el volumen total de tarjetas del EEE) calculado según las PSD2 Normas Técnicas Reglamentarias (RTS).

Es muy importante calcular la tasa según se estipula en la sección 19 de la directiva PSD2 del RTS; de lo contrario, ni MasterCard ni nosotros validaremos la puntuación.
Longitud: máx. 2 caracteres
Formato: entero 1 => 99
Valores aceptados:
  • 1 (representa una tasa de fraude menor o igual a 1 punto básico [pb], que equivale al 0,01 %
  • 2 (representa una tasa de fraude entre 1 pb + - y 6 pbs
  • 3 (representa una tasa de fraude entre 6 pbs + - y 13 pbs)
  • 4 (representa una tasa de fraude entre 13 pbs + - y 25 pbs)
  • 5 (representa una tasa de fraude por debajo de 25 pbs)
Mpi.secureCorporatePayment Pago seguro para empresas Indica que se han utilizado procesos y procedimientos de pago específicos y que se aplica la posible exención de pago seguro para empresas.
Este campo debe ser solo Y si el campo de exención del adquirente se deja en blanco, ya que
la exención del adquirente y el pago seguro se excluyen mutuamente.
No obstante, el servidor de directorio (DS) no validará las condiciones de la extensión. El DS transferirá los datos como se enviaron.
Opcionalmente se puede indicar si se aplican a los procesos y protocolos dedicados según la sección 17 de la directiva PSD2 del RTS, lo que potencialmente permitiría al emisor reclamar la exención del pago seguro para empresas.

Longitud: máx. 1 carácter
Formato aceptado: boolean
Valor aceptado

  • Y
  • N
Mpi.threeDSRequestorChallengeIndicator Indicador de comprobación del comerciante Indica si se requiere una comprobación para esta transacción. Por ejemplo:
Para 01-PA, es posible dudar de la transacción y solicitar una comprobación.
Para 02-NPA, puede ser necesaria una comprobación al añadir una nueva tarjeta a una cartera.

Para órdenes locales/regionales y otras variables.
Longitud: 2 caracteres
Tipo de datos: Cadena
Valores aceptados:
  • 01 = Sin preferencia
  • 02 = Ninguna comprobación solicitada
  • 03 = Comprobación solicitada: preferencia del comerciante  
  • 04 = Comprobación solicitada: orden
  • 05 = Ninguna comprobación solicitada [análisis de riesgo transaccional realizado]
  • 06 = Ninguna comprobación solicitada [solo compartición de datos]
  • 07 = Ninguna comprobación solicitada [SCA ya realizado]
  • 80-99 = Reservado para uso DS

El envío de estos parámetros proporcionará a todas las partes involucradas mucha más información. No solo potenciará los flujos sin problemas: también generará tasas de aprobación más altas y menos casos de fraude.
Ten en cuenta que estos parámetros adicionales solo funcionan con transacciones de MasterCard. Usarlos con cualquier otro método de pago no tendrá ningún efecto.

9.2.4 Comentarios

Tarjetas de prueba

Puede usar las siguientes tarjetas de prueba para simular una tarjeta registrada 3-D Secure en nuestro entorno de prueba:

Flujo sin problemas
Marca Número de tarjeta Fecha de caducidad
VISA 4186455175836497 Cualquier fecha del futuro
Mastercard
5137009801943438 Cualquier fecha del futuro
American Express
375418081197346 Cualquier fecha del futuro

Nota: Puede descargar más número de tarjetas de prueba aquí.

Flujo con comprobación
Marca Número de tarjeta Fecha de caducidad
VISA 4874970686672022 Cualquier fecha del futuro
Mastercard
5130257474533310 Cualquier fecha del futuro
American Express
379764422997381 Cualquier fecha del futuro

Nota: Puede descargar más número de tarjetas de prueba aquí.

Identificación incorrecta

Si una transacción está bloqueada debido a una identificación incorrecta, el resultado de la transacción será:

STATUS = 0

NCSTATUS = 5

NCERROR = 40001134

9.3 Exclusiones y exenciones para 3DsV2

9.3.1 3DSv2 y exclusiones

Con la introducción de 3DSv2, por normal general la autenticación del titular de la tarjeta será obligatoria según lo define la Segunda Directiva de Servicios de Pago (2015/2366 PSD2) de la UE. Sin embargo, algunas transacciones se excluyen de esta regla si se aplica uno de los siguientes escenarios:
  • Pedidos por correo/pedidos por teléfono
  • Viaje de ida: El PSP del beneficiario (también conocido como adquirente del comerciante) o el PSP del pagador (también conocido como emisor del método de pago del comprador) se encuentra fuera de la zona del EEE.
  • Tarjetas prepago anónimas de hasta 150 € (artículo 63)
  • MIT - transacciones iniciadas por el comerciante

9.3.2 Flujo SCA y 3DS sin fricción/con comprobación

Parte de esta nueva normativa es la Autenticación sólida de clientes (SCA). Esto implica la posibilidad de que el emisor (el banco del titular de la tarjeta) solicite información adicional al titular de la tarjeta. En tal escenario, el proceso de autenticación dará como resultado un flujo con comprobación (que requiere que el titular de la tarjeta se autentique de forma activa) en lugar de un flujo sin fricción (que no requiere autenticación por parte del titular de la tarjeta).

Sin embargo, ofrecemos a nuestros comerciantes la posibilidad de indicar su flujo preferido. Esto se puede lograr enviando parámetros adicionales que serán utilizados por el emisor para la evaluación de riesgos. En función de la decisión del emisor, podría tener lugar un flujo sin fricción. En algunos escenarios, 3DS podría incluso omitirse por completo si se aplican exenciones específicas.

9.3.3 Indicación del flujo preferido

Para indicar la preferencia por un flujo sin fricción durante la solicitud de autenticación, el comerciante puede enviar el parámetro adicional Mpi.threeDSRequestorChallengeIndicator. Dependiendo de la evaluación del riesgo de fraude del comerciante, se pueden enviar valores específicos (por ejemplo, para una evaluación de bajo riesgo: 02, para un mayor riesgo de fraude: 03).

Parámetro Valores Obligatorio/Opcional
Mpi.threeDSRequestorChallengeIndicator 01 = Sin preferencia
02 = Ninguna comprobación solicitada
03 = Comprobación solicitada: preferencia del comerciante
04 = Comprobación solicitada: orden
Obligatorio (en caso de una preferencia para un flujo específico)


El comerciante puede aumentar aún más la posibilidad de un flujo/tasa de conversión sin fricción enviando más campos opcionales.

9.3.4 Exenciones de 3DS

Para algunas transacciones, el comerciante puede omitir 3DS (lo que se traduce en un flujo sin fricción) e ir directamente a la autorización. Este proceso está limitado a transacciones que están excluidas de SCA (como se describe anteriormente) o que pueden beneficiarse de exenciones específicas. Estas exenciones deben ser parte de un acuerdo entre el comerciante y su adquirente. En un escenario como este, el comerciante indicará omitir el proceso de autenticación enviando estos parámetros adicionales:


Parámetro Valores Obligatorio/Opcional
FLAG3D
N = Saltar el proceso de autenticación 3DS
Obligatorio (en caso de que deba omitirse 3DS)
3DS_EXEMPTION_INDICATOR Justificación para omitir 3DS. Los valores numéricos pueden ser los siguientes dependiendo de la transacción

03 = TRA* de emisor
04 = Exención baja
05 = TRA* de comerciante/adquiriente
06 = Lista blanca
07 = Corporativo
08 = Envío con retraso
09 = Autenticación delegada (cartera certificada)
Obligatorio (en caso de que deba omitirse 3DS)

* Análisis del riesgo de la transacción (Transaction Risk Analysis)

Sin embargo, sigue siendo decisión del emisor llevarse a cabo o no un proceso de autenticación. Si el emisor insiste en usar 3DS, la transacción será rechazada.