Si eres un nuevo comerciante, ten en cuenta nuestra nueva interfaz para este modo de integración.

Descubre sus prestaciones y posibilidades en nuestra guía especializada en nuestra guía especializada.

Ingenico ePayments DirectLink le permite configurar una integración de servidor a servidor con nuestra plataforma. Mientras que con Ingenico ePayments Página de pago alojada el cliente era redireccionado a la página de pago seguro (alojada por Ingenico ePayments), con DirectLink el cliente permanece en una página propia que enviará de forma segura los datos de pago a nuestros servidores.

También puede usar DirectLink para las tareas de mantenimiento de transacciones, independientemente de que se hayan iniciado en DirectLink o en, por ejemplo, el modo Página de pago alojada.

El gráfico superior muestra el flujo de una transacción con DirectLink

Con DirectLink, no hay contacto entre nuestro sistema y el cliente del comerciante. Su sistema transmite toda la información necesaria para realizar directamente el pago en nuestro sistema en una solicitud HTTPS POST. Nuestro sistema solicita la transacción financiera (de forma sincrónica o asincrónica) a la entidad adquirente correspondiente y devuelve la respuesta a su servidor en formato XML. Su programa lee la respuesta y reanuda su procesamiento.

Será, por tanto, responsable de recopilar y almacenar los detalles de pago confidenciales del cliente y deberá garantizar la confidencialidad y seguridad de estos detalles mediante la seguridad del servidor y la comunicación web cifrada.

Para almacenar datos de tarjeta y personales, debe cumplir con las normas PCI

    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.

    El gráfico superior muestra el flujo de una transacción paso a paso con DirectLink

    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).

    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.

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

    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.

    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 Página de pago alojada). El principio es el mismo en modo Página de pago alojada 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.

    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.

    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.

    • 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.

    La siguiente tabla contiene los parámetros de solicitud para enviar una nueva solicitud de pedido:

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

    Su nombre de afiliación en nuestro sistema.

    Formato: AN, 30

    Obligatorio

    ORDERID

    Su número de pedido único (referencia del comerciante).

    Formato: AN, 40

    Obligatorio

    USERID

    Nombre de su usuario de aplicación (API). Consulte la documentación del Administrador de usuarios para obtener información sobre cómo crear un usuario API.

    Formato: AN, 20 (2. min)

    Obligatorio

    PSWD

    Contraseña del usuario API (USERID).

    Formato: AN

    Obligatorio

    AMOUNT

    Importe a pagar MULTIPLICADO POR 100, ya que el formato del importe no debe contener decimales u otros separadores.

    Formato: N, 15

    Obligatorio

    CURRENCY

    Código de divisa de pedido alfa ISO, por ejemplo: EUR, USD, GBP, CHF, etc.

    Formato: AN, 3

    Obligatorio

    CARDNO

    Número de tarjeta/cuenta.

    Formato: AN, 21

    Obligatorio

    ED

    Fecha de caducidad.

    Formato: MM/AA o MMAA

    Obligatorio

    COM

    Descripción del pedido.

    Formato: AN, 100

    Opcional

    CN

    Nombre del cliente.

    Formato: AN, 35

    Obligatorio

    EMAIL

    Dirección de correo electrónico del cliente. Si estás realizando una petición 3DSv2.1, asegúrate por favor de que el formato del e-mail remitido es válido. De lo contrario, la autenticación de la transacción pasará a ser 3DS 1.0

    Formato: AN, 50

    Opcional

    SHASIGN

    Firma (cadena con hash) para autenticar los datos (consulte Firma SHA-IN).

    Formato: AN, 128

    Obligatorio

    CVC

    Código de verificación de la tarjeta. Dependiendo de la marca de la tarjeta, el código de verificación tendrá 3 o 4 dígitos en la parte delantera o posterior de la tarjeta, una fecha de inicio o una fecha de nacimiento.

    Formato: N, 5

    Obligatorio

    ECOM_PAYMENT_
    CARD_VERIFICATION

    Alternativa a CVC: fecha de nacimiento/número de problema/etc. (dependiendo del país/banco)

    Formato: N, 5

    Opcional

    OWNERADDRESS

    Número y nombre de la calle del cliente.

    Formato: AN, 50

    Opcional

    OWNERZIP

    Código postal del cliente.

    Formato: AN, 10

    Opcional

    OWNERTOWN

    Nombre de la localidad del cliente.

    Formato: AN, 40

    Opcional

    OWNERCTY

    País del cliente, por ejemplo, BE, NL, FR, etc.

    Formato: AN, 2

    Opcional

    OWNERTELNO

    Número de teléfono del cliente.

    Formato: AN, 30

    Opcional

    OPERATION

    Define el tipo de transacción solicitado.

    Puede configurar una operación predeterminada (procedimiento de pago) en la pestaña "Parámetros de transacción globales", en la sección "Valor de ECI predeterminado" de la página Información técnica. Cuando envíe un valor de operación en la solicitud, este sobrescribirá el valor predeterminado.

    Valores posibles:
    • RES: solicitud de autorización
    • SAL: solicitud de venta directa
    • RFD: reembolso, no vinculado con un pago anterior. Por ejemplo, una operación de que no es de mantenimiento en una transacción existente (no se puede utilizar esta operación sin permiso específico de su entidad adquirente).

    Opcional:

    • PAU: Solicitud de preautorización:
      De acuerdo con la entidad adquiriente puede utilizar este código de operación para reservar fondos de forma temporal en la tarjeta de un cliente. Se trata de una práctica común en el sector de viajes y alquiler.
      En estos momentos, PAU/preautorización solo se puede utilizar en transacciones de MasterCard y es compatible con entidades adquirientes seleccionadas. Este código de operación no se puede definir como valor predeterminado en su cuenta de Ingenico ePayments.
      En el caso de que utilice PAU en transacciones a través de entidades adquirientes o con marcas de tarjetas que no admiten preautorización, estas transacciones no se bloquearán, sino que se procesarán como autorizaciones (RES) normales.

    Formato: A, 3

    Obligatorio

    WITHROOT

    Añade un elemento raíz a nuestra respuesta XML. Valores posibles: ‘Y’ o vacío.

    Formato: Y o <vacío>

    Opcional

    REMOTE_ADDR

    Dirección IP del cliente (solo para el módulo de detección de fraude). Si no es necesario realizar una comprobación de país en la dirección IP, envíe "NONE".

    Formato: AN

    Opcional

    RTIMEOUT

    Tiempo de espera de solicitud para la transacción (en segundos, valor entre 30 y 90)

    Importante: El valor definido aquí debe ser inferior al valor de tiempo de espera de su sistema (!)

    Formato: N, 2

    Opcional

    ECI

    Indicador de comercio electrónico.

    Puede configurar un valor ECI predeterminado en la página Información técnica de su cuenta, pestaña "Parámetros de transacción globales", sección "Valor ECI predeterminado". Cuando envíe un valor ECI en la solicitud, este sobrescribirá el valor ECI predeterminado.

    Posibles valores (numéricos):
    0 - Pasada por el lector
    1 - Introducción manual (MOTO) (tarjeta no presente)
    2 - Periódico (desde MOTO)
    3 - Pagos a plazo
    4 - Introducción manual, tarjeta presente
    7 - Comercio electrónico con cifrado SSL
    9 - Periódico (desde comercio electrónico)

    Formato: N, 2

    Opcional


    Si procesas pagos recurrentes, debes añadir parámetros Credentials-on-file (COF) a tu solicitud.

    Consulta nuestra guía de Administrador de alias (tokenización) para obtener información detallada sobre el procesamiento de transacciones COF.


    La lista de posibles parámetros que enviar puede ser más larga para comerciantes que hayan activado determinadas funcionalidades/opciones en sus cuentas. Consulte la documentación de la opción correspondiente para obtener más información acerca de los parámetros adicionales vinculados a la opción.

    Los siguientes parámetros de solicitud son obligatorios en los pedidos nuevos:

    • PSPID y USERID
    • PSWD
    • ORDERID
    • AMOUNT (x 100)
    • CURRENCY
    • CARDNO
    • ED
    • CVC
    • OPERATION


    Cumplir la elección de la marca de tu cliente para las tarjetas mixtas

    En algunos casos, también se emite una tarjeta de crédito internacional (por ejemplo, Visa/MasterCard) para un segundo método de pago local. Estas tarjetas de crédito reciben el nombre de tarjetas mixtas.  

    Si ofreces métodos de pago locales además de planes internacionales, necesitas ofrecer a tus clientes las distintas marcas que aparecerán en la tarjeta emitida

    Para ello, es importante


    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.

    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.


    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.

    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.


    Consulta nuestra guía de Administrador de alias (tokenización) para obtener información detallada sobre el procesamiento de transacciones COF.

    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.

    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”.

    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.
    • 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.

    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

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

    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.

    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.

    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).

    • 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.

    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

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

    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.

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

    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 Página de pago alojada.

    Ejemplo de una respuesta XML a una consulta directa para una transacción de Página de pago alojada

    <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"/>

    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

    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.

    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.

    • 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.

    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.

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

    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>

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

    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)

    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)

    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.

    Para obtener información general sobre 3-D Secure v2, consulta nuestra guía de PSD2.

    Aprenda aquí a implementar 3-D Secure de forma segura en el proceso de pago.

    El flujo de transacciones incluye los siguientes pasos:

    1. Tu cliente va a tus páginas de pago y finaliza la compra en tu página de pago
    2. Tú nos envías la información del pedido y los detalles de pago a través de una solicitud de DirectLink, que contiene una serie de parámetros adicionales
      • (2) Opcional: llevamos a cabo un control del fraude.
    3. Recibes una respuesta XML de nuestra plataforma. Pueden darse dos escenarios
      • Si la transacción se realiza a través de un flujo sin fricción, la respuesta contiene los parámetros estándar con la información final de la transacción. Esto marca el final del flujo.

      • Si la transacción pasa por el flujo de comprobación, la respuesta contiene el campo adicional HTML_ANSWER y un estado de pago específico (STATUS=46). HTML_ANSWER contiene un bloque de código con codificación BASE-64.

    4. Añade el bloque de código sin cifrar al navegador del titular de la tarjeta. El titular de la tarjeta es redirigido automáticamente a su banco emisor para su autenticación.
    5. El titular de la tarjeta se identifica. Nuestro sistema recibe el resultado del emisor
    6. En función del resultado, pueden darse dos escenarios
      • Si la identificación no se produce correctamente, redirigimos al titular de la tarjeta a DECLINEURL y finaliza el flujo. Recibes el resultado a través de los canales de información del modo Página de pago alojada.
      • Si la identificación se produce correctamente, presentamos la transacción financiera real al comprador para procesar la transacción
    7. Te devolvemos el resultado del pago. Dependiendo del resultado del comprador, redirigimos al titular de la tarjeta a ACCEPTURL/DECLINEURL/EXCEPTIONURL. Recibes el resultado a través de los canales de información del modo Página de pago alojada.
    8. Si la transacción se realiza correctamente, puedes entregar los bienes/servicios

    DirectLink with 3-D Secure v2 transaction flowThis graph describes the DIRECTLINK (DPR/D3D) + Fraud transaction flow

    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.

    Para procesar transacciones con 3-D Secure, debes enviar un conjunto de parámetros obligatorios, recomendados y opcionales a nuestra plataforma.

    Estos parámetros deben incluirse en el cálculo SHA.

    Capturar y enviar parámetros

    Necesitas capturar los parámetros obligatorios/recomendados/opcionales específicos de 3DS en tu página de pago. 

    Aquí tienes un bloque de código Javascript que puedes usar para capturar la información del navegador.

    <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>

    Envíe estos parámetros específicos de 3-D Secure junto con los otros parámetros obligatorios de DirectLink. Nuestra plataforma procesará tu solicitud y te dará una respuesta.

    Comprender las transacciones rechazadas

    PSD2 aumenta la transparencia del proceso de pago para ti y para tus clientes. Esto es especialmente útil cuando se trata de transacciones de estado 2.
    Nuestro parámetro de información CH_AUTHENTICATION_INFO te proporciona información detallada de los emisores cuando rechazan las transacciones de tus clientes. Puedes compartir esta información con tus clientes para ayudarles a entender por qué su banco rechazó su transacción. Esta información también podría ayudarte a recuperar la transacción utilizando nuestra función Soft Decline.

    Para recibir CH_AUTHENTICATION_INFO en la respuesta XML y en tus URL de redireccionamiento, selecciona este parámetro en Back Office desde Configuración > Información técnica > Respuesta transacción > Parámetros dinámicos de comercio electrónico y DirectLink > Parámetros dinámicos respectivamente. Esto también asegurará que esta información sea visible en el resumen de la transacción a través de Operaciones > Ver transacciones / Historial financiero.

    Utiliza CH_AUTHENTICATION_INFO para cada posible escenario:

    • Si la transacción se realiza con el Flujo sin problemas, nuestra respuesta XML contendrá este parámetro. Añade la información a la página de resultados de la transacción en consecuencia.
    • Si la transacción se realiza con el challenge flow, recibirás este parámetro a través de canales de información del modo. Como no recibirás la información con la suficiente antelación para modificar tus URL de redireccionamiento una vez finalizada la transacción, te recomendamos que marques "Deseo que Ingenico ePayments muestre un texto breve al cliente en la página de pago seguro si se detecta un redireccionamiento a mi sitio web inmediatamente después del proceso de pago." en Back Office desde Configuración > Información técnica > Respuesta transacción > eCommerce > Redireccionamiento HTTP en el navegador. Nuestra plataforma redirigirá entonces a tus clientes a nuestra página de resultados intermedios mostrando la información antes de que los clientes terminen en tus URL de redireccionamiento.

    Recuerda que no todos los emisores comparten información sobre las razones por las que rechazan las transacciones. Por ello, en algunos casos CH_AUTHENTICATION_INFO está vacío.

    Utiliza los siguientes números de tarjeta en nuestro Entorno de prueba para simular una respuesta del emisor:
    Amex: 349586710563469
    MasterCard: 5111823134937549
    Visa: 4010759044222272

    Procesamiento de la respuesta de la plataforma

    Si la transacción se realiza a través de un flujo sin fricción, la respuesta contiene los parámetros estándar con la información final de la transacción. Esto marca el final del flujo.

    Si la transacción pasa por el flujo de comprobación, la respuesta contiene parámetros adicionales. Para desplegar la autenticación a tus clientes, es necesario procesar los datos adicionales proporcionados como se describe aquí:

    Campo Descripción
    ESTADO 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.

    Si la identificación no se produce correctamente, redirigimos al titular de la tarjeta a DECLINEURL y finaliza el flujo. Recibes el resultado a través de los canales de información del modo Página de pago alojada.

    Si la identificación se produce correctamente, presentamos la transacción financiera real al comprador.

    Dependiendo del resultado del comprador, redirigimos al titular de la tarjeta a ACCEPTURL/DECLINEURL/EXCEPTIONURL. Recibes el resultado a través de los canales de información del modo Página de pago alojada.

    9.3 Tarjetas de prueba

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

    <th">

    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
    Carte Bancaire 4150557357382737 Cualquier fecha del futuro
    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
    Carte Bancaire 4150550997933993 Cualquier fecha del futuro

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

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

    STATUS = 2

    NCERROR = 40001134

    9.4 Exclusiones de la regla 3DSv2

    Algunas transacciones quedan excluidas de PSD2.Si alguna de tus transacciones está entre ellas, no se implementará 3-D Secure. Esto también se aplica a las transacciones recurrentes que inicies. Para marcar estas transacciones denominadas MIT (transacciones iniciadas por comercios) como tales, es necesario enviar parámetros adicionales a nuestra plataforma.

    Puedes solicitar omitir 3-D Secure durante


    Elige solo uno de los métodos cuando solicites las transacciones, ya que son mutuamente excluyentes.

    Flujo sin fricción/con comprobación e indicación del flujo preferido

    Puedes aumentar la posibilidad de omitir el SCA (y realizar un flujo sin fricción) enviando el siguiente parámetro.

    Dependiendo de la evaluación del riesgo de fraude, 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

    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
    Obligatorio (en caso de una preferencia para un flujo específico)

    Puedes incluso aumentar la posibilidad de un flujo sin fricción y una mayor tasa de conversión enviando más campos opcionales.

    Exenciones de 3DS

    Para omitir por completo 3-D Secure, envía los siguientes parámetros:

    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)

    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.

    Important

    Las transacciones para las que se debe omitir 3-D Secure solo pueden ser procesadas como autorizaciones (que terminarán en el estado 5 si se producen correctamente). Para revisar los fondos de estas transacciones, deberás capturarlas más adelante. La transacción capturada correctamente alcanzará el estado 9.

    Soft Decline

    Un flujo típico de una transacción con rechazo suave es el siguiente:

    1. En la primera solicitud, se envía solo FLAG3D=N sin ningún otro parámetro de autenticación. Es la forma de indicar que quieres omitir 3-D Secure. Es posible que la transacción se admita en este momento.
      Si es rechazada por el banco de tu cliente porque insiste en 3-D Secure, lo indicaremos en el parámetro de comentarios enviando NCERROR=40001139. La transacción se pondrá en estado 2.
    2. Para recuperar esta transacción rechazada, vuelve a enviar la transacción con los siguientes parámetros a nuestra plataforma:
      1. Los parámetros de e-Commerce DirectLink parameters estándar tal y como se incluyeron en la primera solicitud como un nuevo pedido de eCommerce o DirectLink
      2. FLAG3D=Y para indicar que es preciso desplegar 3-D Secure
      3. Los parámetros de autenticación 3DSv2  as described here
      4. Mpi.threeDSRequestorChallengeIndicator=04 para indicar el que el banco de tu cliente insiste en 3-D Secure tras el Soft Decline.

    Tu cliente tendrá que pasar la autenticación 3-D Secure en esta segunda solicitud. Por último, la transacción pasará al estado 2 o 9. Esto depende de si tu cliente ha pasado la autenticación y de si el pago es aceptado tanto por tu banco como por el de tu cliente.

    Soft Decline está disponible actualmente para métodos de pago Visa, MasterCard, American Express y Carte Bancaire.

    9.5 Pasar de la v2.1 a la v2.2

    La próxima versión de 3-D Secure (v2.2) te ofrecerá aún más posibilidades para optimizar tu integración.

    En la versión actual de 3-D Secure v2.1, este parámetro es opcional, pero será obligatorio cuando esté disponible la versión 2.2. Implantarlo ahora garantizará una transición fluida de la v2.1 a la v2.2.

    Parameter Values

    BROWSERJAVASCRIPTENABLED

    Este booleano indica si tus clientes han activado JavaScript en sus navegadores al realizar una compra.

    En función de su valor, se aplica lo siguiente:

    • TRUE: los siguientes parámetros seguirán siendo obligatorios:

      BROWSERJAVAENABLED
      BROWSERSCREENHEIGHT
      BROWSERSCREENWIDTH
      BROWSERTIMEZONE
      BROWSERACCEPTHEADER
      BROWSERUSERAGENT
      BROWSERLANGUAGE

    • FALSE: los siguientes parámetros ya no son obligatorios:
      BROWSERCOLORDEPTH
      BROWSERJAVAENABLED
      BROWSERSCREENHEIGHT
      BROWSERSCREENWIDTH
      BROWSERTIMEZONE

      Este parámetro sigue siendo obligatorio:

      BROWSERACCEPTHEADER
      BROWSERUSERAGENT
      BROWSERLANGUAGE

    Tipo de datos: Boolean

    Valores aceptados:
    • TRUE
    • FALSE

    Si no envías este parámetro, nosotros lo rellenamos previamente en función de los demás parámetros disponibles.

    Además de BROWSERJAVASCRIPTENABLED, la v2.2 ofrece parámetros mejorados/nuevos para que tus transacciones sean aún más seguras:

    3DSv1 es el primer protocolo de seguridad en 3 dimensiones de los sistemas de tarjetas y ha sido reemplazado por la versión 2 (v2). Si ya has implementado la v2, esta sección no se te aplica.

    Recomendamos encarecidamente adaptar la implementación según los requisitos de la v2. Sin embargo, si aún no estás listo, aquí tienes las instrucciones para implementar la v1.

    Flujo de la transacción de 3-D Secure v1 a través de DirectLink

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

    1. Tu cliente va a tus páginas de pago y finaliza la compra en tu página de pago
    2. Tú nos envías la información del pedido y los detalles de pago a través de una solicitud de DirectLink, que contiene una serie de parámetros adicionales.
      • (2) Opcional: llevamos a cabo un control del fraude.
    3. Recibes una respuesta XML de nuestra plataforma.
      • Si la tarjeta del cliente no está registrada para 3-D Secure, la respuesta contiene los parámetros estándar con la información final de la transacción.
      • Si la tarjeta del cliente está registrada para 3-D Secure, la respuesta contiene el campo adicional HTML_ANSWER y un estado de pago específico (STATUS=46). HTML_ANSWER contiene un bloque de código con codificación BASE-64.
    4. Añade el bloque de código sin cifrar al navegador del titular de la tarjeta. El titular de la tarjeta es redirigido automáticamente a su banco emisor para su autenticación.
    5. El titular de la tarjeta se identifica. Nuestro sistema recibe el resultado del emisor
    6. Two scenarios are possible
    7. Te devolvemos el resultado del pago. Dependiendo del resultado, redirigimos al titular de la tarjeta a ACCEPTURL/DECLINEURL/EXCEPTIONURL. Recibes el resultado a través de los canales de información del modo Página de pago alojada .
    8. Si la transacción se realiza correctamente, puedes entregar los bienes/servicios
    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.

    Envío de solicitud de 3-D Secure v1

    Para procesar transacciones con 3-D Secure, debes enviar un conjunto de parámetros obligatorios y opcionales a nuestra plataforma.

    En esta tabla puedes ver una descripción general de los diferentes parámetros y su finalidad para el proceso de autenticación

    Estos parámetros deben incluirse en el cálculo SHA.

    Parameter category Parametros Nombre / Descripción
    obligatorios

    FLAG3D

    Valor fijo: ‘Y’

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

    HTTP_ACCEPT*

    Este parámetro ha sido reemplazado por browserAcceptHeader. No lo envíes si ya estás enviando browserAcceptHeader.

    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*

    This parameter has been replaced by browserUserAgent. Do not send it if you are already sending browserUserAgent.

    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)

    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.

    LANGUAGE

    El idioma predeterminado se utiliza si no se envía un valor de idioma o este valor no es válido: en_US (inglés)

    opcionales

    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).

    PARAMPLUS

    Field to submit the miscellaneous parameters and their values that you wish to be returned in the post-sale request or final redirection.

    COMPLUS

    Field to submit a value you wish to be returned in the post-sale request or output.

    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.

    Tras enviar estos parámetros, nuestra plataforma procesará tu solicitud y te dará una respuesta.

    Procesamiento de la respuesta de la plataforma

    Si la tarjeta del cliente no está registrada para 3-D Secure, la respuesta contiene los parámetros estándar con la información final de la transacción. Esto marca el final del flujo.

    Si la tarjeta del cliente está registrada para 3-D Secure, la respuesta contiene parámetros adicionales. Para desplegar la autenticación a tus clientes, es necesario procesar los datos adicionales proporcionados como se describe aquí:

    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.

    Si la identificación no se produce correctamente, redirigimos al titular de la tarjeta a DECLINEURL y finaliza el flujo. Recibes el resultado a través de los canales de información del modo Página de pago alojada.

    Si la identificación se produce correctamente, presentamos la transacción financiera real al comprador.

    Dependiendo del resultado del comprador, redirigimos al titular de la tarjeta a ACCEPTURL/DECLINEURL/EXCEPTIONURL. Recibes el resultado a través de los canales de información del modoPágina de pago alojada.

    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

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

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

    STATUS = 2

    NCERROR = 40001134

    9.7 Consulta una descripción general de las transacciones 3-D Secure

    Te ofrecemos una forma de acceder a tu informe 3DS desde el Back Office para poder hacer un seguimiento de tus transacciones y de los resultados de 3-D Secure.

    Mira este vídeo en el que se explica cómo configurar el informe de forma rápida y sencilla.

    Preguntas más frecuentes

    En el menú de su cuenta de Ingenico ePayments, puede fácilmente buscar las transacciones seleccionando "Operaciones" y haciendo clic en "Ver transacciones" o "Historial financiero", dependiendo del tipo de resultados de transacción que busque.

    Vaya a Consulte sus transacciones para obtener más información.

    De forma predeterminada, puede enviar bienes o entregar su servicio después de que una transacción haya alcanzado el estado "5 - Autorizado" o "9 - Pago solicitado". No obstante, aunque el estado 5 es un estado satisfactorio, es únicamente una reserva temporal de un importe de dinero en la tarjeta del cliente. Una transacción en estado 5 sigue necesitando ser confirmada (manual o automáticamente), para pasar el estado 9, que es el estado satisfactorio final de la mayoría de los métodos de pago.

    Vaya a Estados de transacciones para obtener más información.

    Puede reembolsar un pago fácilmente con el botón "Reembolso" en la descripción del pedido de una transacción (mediante Ver transacciones). Si su cuenta lo admite, también puede realizar reembolsos con una solicitud de DirectLink o con una carga de archivo de Fichero de Lote (para varias transacciones).

    Tenga en cuenta que la opción Reembolsos debe estar activada en su cuenta.
    Vaya a Mantenimiento de transacciones para obtener más información.

    Si desea comprobar los detalles específicos de un pedido o una transacción, o realizar el mantenimiento en las transacciones, debe utilizar "Ver transacciones".
    El "historial financiero" es lo más cómodo para comprobar periódicamente los fondos entrantes y salientes por (lotes de) transacciones, y realizar la conciliación.

    Si desea obtener más información, vaya a Ver transacciones frente a Historial financiero

    Solo puede realizar reembolsos en transacciones cuyo estado es "9 - Pago solicitado". Se puede realizar una cancelación o eliminación tras aproximadamente 24 horas de haber recibido un estado definitivo ( 5-Autorizado o 9 – Pago solicitado ) . 
    Para conocer la hora límite de la entidad adquirente, le recomendamos que consulte con el departamento de atención al cliente.