Después del pago

Después de realizar el pago puedes gestionarlo en el panel personal del portal del vendedor o a través de API. Lee las secciones a continuación para saber más.

Cancelación y devolución de pago

Si desea cancelar un pago, puede realizar una de dos operaciones, dependiendo del estado del pedido: cancelación o devolución. Estas operaciones se describen a continuación.

Cancelación

Cancelación significa que la transacción se cancela, y todos los fondos reservados en la cuenta del cliente se desbloquean. Esta operación puede aplicarse a transacciones de dos etapas, cuando los fondos están reservados, pero aún no recibidos (estado Confirmado). Después de la cancelación, la transacción obtiene el estado Cancelado.

Están disponibles los siguientes métodos de cancelación:

• Cancelación de pago en el portal del vendedor. Se realiza presionando el botón Devolución en la página de detalles de la operación. Este botón funciona tanto para la cancelación de pago, como para la devolución de fondos – dependiendo del estado de la transacción. Si es posible, ocurre la cancelación de pago, y si no, se realiza la devolución de fondos. Lea más aquí.

• Cancelación de pago a través de API enviando una solicitud reverse.do.

• Cancelación de todos los pagos de dos etapas automáticamente al vencimiento de cierto tiempo. Si necesita esta funcionalidad, contacte al servicio de soporte del banco.

La cancelación solo puede realizarse antes del final del día bancario actual.

Devolución de fondos

Devolución significa la devolución al cliente de los fondos ya debitados. Esta operación puede aplicarse a transacciones de una etapa y dos etapas, cuando los fondos ya han sido debitados (estado Completado). El sistema permite devolver fondos más de una vez, pero en total no más del importe inicial de completación.

Son posibles los siguientes métodos de procesamiento de devolución:

• Devolución de fondos en el panel personal presionando el botón Devolución en los detalles de la transacción. Este botón funciona tanto para la cancelación de pago, como para la devolución de fondos – dependiendo del estado de la transacción. Si es posible, ocurre la cancelación de pago, y si no, se realiza la devolución de fondos. Lea más aquí.
• Devolución de fondos a través de API enviando una solicitud refund.do.

Tanto la cancelación como el reembolso pueden ser asignados por triggers de notificaciones callback. Lea más detalles aquí.

Obtención del estado del pedido

Puede verificar el estado del pedido en cualquier momento. Por ejemplo, puede verificarlo después del pago para asegurarse de que el pedido realmente esté pagado. El estado del pedido está disponible en el portal del vendedor, y también puede obtenerse a través de API.

Determinación del estado del pedido en el portal del vendedor

El estado del pedido se puede consultar en la página Detalles de la transacción de la transacción correspondiente.

El estado Deposited significa pago exitoso.

Determinación del estado del pedido a través de API

Para obtener el estado del pedido, la tienda online envía a la pasarela de pago una solicitud getOrderStatusExtended.do. La solicitud contiene ya sea orderId (número único del pedido en la pasarela de pago), o orderNumber (número único del pedido en el sistema de la tienda online). Si en la solicitud se transmiten ambos parámetros, la prioridad de orderId es mayor.

La pasarela de pago devuelve el estado del pedido en el parámetro orderStatus. El estado 2 significa pago exitoso.

Funcionalidades adicionales

Pagos de dos etapas

Tipos de pagos

Dependiendo de las especificidades del negocio, la empresa puede utilizar dos tipos de pagos:

• De una etapa - operaciones de pago de bienes/servicios realizadas a través de Internet utilizando tarjetas bancarias, que no requieren confirmación adicional, es decir, la retención y el débito de los fondos monetarios ocurre en una etapa. Este tipo de pago es preferible si el bien o servicio se proporciona inmediatamente después del pago.
• De dos etapas - operaciones de pago de bienes/servicios realizadas a través de Internet utilizando tarjetas bancarias, que requieren confirmación adicional, es decir, el pago se realiza en dos etapas. En la primera etapa ocurre la verificación de disponibilidad y retención (reserva) de los fondos del pagador (preautorización); luego en la segunda etapa la empresa confirma el débito de fondos o cancela la retención de fondos.

La suma de finalización puede ser menor que la suma de retención. También existe la posibilidad de hacer finalizaciones por una suma que exceda la magnitud de retención (dentro de los límites configurables). Si desea utilizar esta funcionalidad, contacte con nuestro servicio de soporte.

Los pagos de dos etapas se deben utilizar si entre la toma de decisión del comprador sobre el pago y la entrega del bien o servicio seleccionado transcurre algún tiempo.

Para que el pago sea de dos etapas, el pedido debe ser registrado con ayuda de la solicitud registerPreAuth.do, y no register.do.

El pago de dos etapas es posible con cualquier método de integración:

• Pago por enlace
  
• Integración a través de redirección
• Pagos directos
• CMS
• SDK

Para las variantes de integración directa, integración a través de redirección, CMS, SDK es posible el registro y procesamiento del pedido a través de API.

Finalizaciones

La finalización ocurre en la segunda etapa del pago de dos etapas, cuando los fondos previamente reservados se debitan de la cuenta del portador de la tarjeta. Tan pronto como ocurre el débito, el pedido se vuelve finalizado y pasa al estado DEPOSITED. La suma de finalización puede ser mayor o menor que la suma de autorización preliminar. También está disponible la finalización parcial por etapas. Si no transmite la suma, será debitada toda la suma.

Hay tres formas de hacer la finalización:

• Finalización del pago en el portal del vendedor
• Finalización del pago a través de API
• Finalización automática de todos los pagos de dos etapas después de algún tiempo

También existe la posibilidad de hacer finalización parcial. En este caso el pedido será finalizado por una suma menor (que la suma de autorización).

Finalización y cancelación de pedidos automáticamente

Si nuestro servicio de soporte ha habilitado esta función para usted, puede configurar su integración para que todas las órdenes de dos etapas preautorizadas (en estado Confirmado) se completen o cancelen automáticamente después de un período de tiempo determinado. En este caso, no necesita procesar cada orden manualmente en el panel de control personal. Tampoco es necesario llamar a los métodos API deposit.do y/o reverse.do.

Para habilitar la finalización automática de órdenes en el panel de control personal:

1. Inicie sesión en el panel de control personal.
2. En el panel de control izquierdo vaya a la sección Configuraciones. .
3. Vaya a la pestaña General.
4. En la sección Finalización automática, marque Finalización automática habilitada.
5. En el campo Plazo de finalización (en horas) ingrese la cantidad de horas después del registro, tras las cuales la orden de dos etapas debe completarse automáticamente.

También puede habilitar la cancelación automática de órdenes. En este caso, todas las órdenes de dos etapas preautorizadas (en estado Confirmado) se cancelarán automáticamente después del período de tiempo especificado. La cancelación significa que la transacción se cancela y todos los fondos reservados en la cuenta del cliente se desbloquean.

Puede establecer la fecha y hora de finalización automática y cancelación automática por API usando los parámetros autocompletionDate y autoReverseDate en las solicitudes API registerPreAuth.do e instantPayment.do. Zona horaria utilizada: UTC+0.

A continuación se describe la lógica de funcionamiento de la finalización automática y cancelación automática.

Cuando una orden está registrada y tiene configurada la finalización automática:

• Si el estado de la orden permanece Creado al momento de llegada del tiempo de finalización automática, no pasará nada con la orden: finalmente su plazo expirará y será cerrada. Si la orden se completa después del período especificado, la finalización automática no se activará.
• Si la orden está preautorizada y no se completa antes del vencimiento del período de finalización predeterminado, la orden será completamente ejecutada, es decir, el monto preautorizado será acreditado automáticamente en su totalidad.
• Si la orden está preautorizada y completada antes del vencimiento del período de finalización especificado, el estado de la orden cambiará de acuerdo con su ciclo de vida normal.
• Si antes del vencimiento del período de finalización especificado se aplica un reembolso/cancelación a la orden, la finalización automática no se activará.

Cuando una orden está registrada y tiene configurada la cancelación automática:

• Si el estado del pedido permanece Creado en el momento de llegada del tiempo de autocancelación, no ocurrirá nada con el pedido: finalmente su plazo expirará y será cerrado. Si el pedido es completado después de transcurrido el período establecido, la autocancelación no se activará.
• Si el pedido está preautorizado y no se completa antes de que expire el período de cancelación predeterminado, el pedido será completamente cancelado, es decir, la suma preautorizada será automáticamente anulada en su totalidad.
• Si el pedido está preautorizado y se completa antes de que expire el período de cancelación establecido, el estado del pedido cambiará de acuerdo con su ciclo de vida habitual.
• Si antes de que expire el período de cancelación establecido se aplica una devolución/cancelación al pedido, la autocancelación no se activará.

Operaciones por datos de pago guardados

La transacción por datos de pago guardados se utiliza cuando el titular de la tarjeta permite al vendedor almacenar los datos de pago para futuros pagos. Por ejemplo, el pagador puede elegir guardar su tarjeta al procesar un pedido. En este caso se crean datos de pago guardados (CoF, credential on file), un token único protegido, generado por la pasarela de pagos, que vincula el número de tarjeta del pagador (PAN) con su identificador en el sistema de la tienda (por ejemplo, con el login del pagador).

Lea más sobre los tipos de datos de pago guardados compatibles con la pasarela de pagos aquí.

Creación de datos de pago guardados

Puede crear datos de pago guardados a través de API o a través del panel personal (independientemente del tipo de integración). Ver más detalles a continuación.

Creación de datos de pago guardados a través de API

Para guardar la tarjeta (crear datos de pago guardados) en la pasarela de pagos a través de API, necesita pasar el parámetro clientId en la solicitud de registro de pedido o iniciación de pago. clientId - es el identificador de su cliente (propietario de la tarjeta), a este número estarán vinculadas todas las tarjetas del cliente. Para propósitos de prueba puede usar cualquier número como clientId. Este parámetro se puede pasar en las siguientes solicitudes:

• register.do
• registerPreauth.do
• instantPayment.do
• motoPayment.do
• /applepay/payment.do
• /applepay/paymentDirect.do
• /google/payment.do
• /google/paymentDirect.do
• /samsung/payment.do
• /samsung/paymentDirect.do

Los datos de pago guardados se crearán solo después del pago exitoso. Después del pago podrá obtener el identificador de datos de pago guardados a través de la solicitud getOrderStatusExtended.do en el parámetro bindingId.

Creación de datos de pago guardados a través del panel personal

Para crear datos de pago guardados al pagar a través de la interfaz de usuario vaya al panel personal, emita una factura al correo electrónico especificando el parámetro Identificador del cliente. Si especifica este parámetro, el cliente verá la casilla Guardar mi tarjeta en la página de pago. Si el cliente marca esta casilla, después de completar el pago se crearán datos de pago guardados, y el cliente no necesitará introducir los datos de la tarjeta la próxima vez. Lea más detalles aquí.

Creación de datos de pago guardados sin pago

Con los derechos de usuario correspondientes, puede crear datos de pago guardados a través de API sin realizar un pago. Esto se puede hacer de las siguientes maneras:

• Transmita el valor VERIFY en el bloque features de cualquier solicitud de pago junto con el parámetro clientId. En este caso no se cobrará ninguna suma al portador de la tarjeta. La respuesta contendrá el identificador de los datos de pago guardados creados en el parámetro bindingId. Este identificador de datos de pago guardados se puede utilizar en solicitudes posteriores en lugar de los datos guardados de la tarjeta.

  Conozca más sobre la función VERIFY aquí.

• Utilice la solicitud de creación de datos de pago guardados sin realizar el pago createBindingNoPayment.do.

Creación forzada de datos de pago guardados

Si transmite el valor FORCE_CREATE_BINDING en el bloque features de la solicitud de pago, los datos de pago guardados se crearán de manera forzada, incluso si el cliente decidió no guardar los datos de la tarjeta en la página de pago.

El valor FORCE_CREATE_BINDING no se puede transmitir en una solicitud con bindingId existente o cuando bindingNotNeeded = true (causará error de verificación). Para transmitir este valor también se requiere transmitir el parámetro clientId.

Si en el bloque features se transmiten ambos valores FORCE_CREATE_BINDING y VERIFY, entonces el pedido se creará SOLO para crear datos de pago guardados (sin pago).

Procesamiento de pago por datos de pago guardados

Trabajo con datos de pago guardados a través de API

Después de crear los datos de pago guardados puede trabajar con ellos a través de API (si tiene permiso a nivel de comerciante). Están disponibles los siguientes métodos:

• paymentOrderBinding.do – procesamiento de pago por datos de pago guardados
• getBindings.do – obtener lista de datos de pago guardados del cliente
• getBindingsByCardOrId.do – obtener lista de todos los datos de pago guardados de la tarjeta bancaria
• unBindCard.do – desactivar datos de pago guardados existentes
• bindCard.do – reactivar datos de pago guardados previamente desactivados
• extendBinding.do — extender el período de validez de los datos de pago guardados.

Uso de datos de pago guardados en pagos recurrentes

Puede utilizar los datos de pago guardados para pagos recurrentes. En este caso el parámetro bindingId se utiliza en la solicitud habitual de registro de pedido. Lea más detalles aquí.

Uso de datos de pago guardados al pagar con billeteras

También puede crear datos de pago guardados al realizar pagos a través de billeteras Apple Pay, Google Pay y Samsung Pay. Para esto es necesario transmitir el parámetro clientId en la solicitud de pago o en la solicitud de procesamiento de pedido (ver descripción de solicitudes API para billeteras).

En este caso los datos de pago guardados conectarán el número de tarjeta tokenizada del pagador (DPAN) con su ID en el sistema de la tienda (por ejemplo, con el login del pagador). Tales datos de pago guardados no se pueden utilizar para mostrar el número de tarjeta en la página de pago (ya que el número de tarjeta está tokenizado). Sin embargo, estos datos de pago guardados se pueden utilizar en pagos recurrentes.

Operaciones de práctica industrial

Introducción

A las transacciones MIT (Merchant-initiated Transaction) Industry Practice, ejecutadas después de la transacción CIT (Cardholder-initiated Transaction) iniciadora, pertenecen las transacciones del siguiente tipo:

• Incremental Authorization Transaction (aumento del importe)
• Resubmission Transaction (reenvío de transacción)
• Delayed Charges Transaction (transacción de pago diferido)
• Reauthorization Transaction (transacción de reautorización de pago)
• No Show Transaction (transacción de pago por no presentación)

Esta funcionalidad está disponible con el permiso correspondiente. Para su activación, diríjase al servicio de soporte técnico.

Condiciones de posibilidad de ejecución de pagos Industry Practice:

1. El permiso para realizar pagos Industry Practice está activado.
2. El pago original fue ejecutado utilizando autenticación 3DS 2.0/2.1/2.2 con tipo frictionless/challenge para transacciones Resubmission, Reauthorization y challenge para Incremental, Delayed charges, No show.
3. El pago original representa un pedido de una etapa en estados erróneos para transacciones Resubmission, Reauthorization, así como en estado Completado para operaciones Incremental, Delayed charges, No show.
4. Pedido original con pago *.Pays tokenizado.
5. Transacción CIT original con tii = CI, RI, II, F (más detalles sobre los tipos de transacciones CIT descritos aquí).
6. En el Merchant la funcionalidad de vínculos está desactivada o se utilizan vínculos V2 (se utilizan vínculos como normales, recurrentes y a plazos).

La ejecución de pagos Industry Practice es imposible para los siguientes tipos de operaciones originales con:

• Tipo 3RI.

• Tipo MIT.

• Pago SSL.

• Tipo MOTO.

• Esquema de pago de dos etapas. Incluyendo completaciones simples o múltiples.

• Con tii = R, I, U.

• Con uso de autenticación 3DS 1.0.

• Con features = VERIFY, donde después de la verificación de datos de tarjeta no hay autorización financiera o fue cancelada.

• En caso de que el Merchant utilice vínculos V1.

Petición API

Para el pago del pedido con características de transacción Industry Practice se utiliza la petición /industryPractice/paymentOrder.do.

Particularidades de ejecución del pago

Para cada uno de los tipos de pago Industry Practice son propias sus condiciones para una ejecución exitosa.

Industry Practice Incremental

• La ejecución es posible solo en el mismo día hábil con relación a la operación original (cuyo importe está sujeto a aumento).
• La ejecución es posible por Comerciantes con los siguientes MCC:
  
  • 3351-3500, 7512 Car Rental;
  • 3501-3999, 7011 Lodging;
  • 4111 Local and Suburban Commuter Passenger Transportation, including Ferries;
  • 4112 Passenger Railways;
  • 4121 Taxicabs and Limousines (Card-Absent Environment only);
  • 4131 Bus Lines;
  • 4411 Steamship and Cruise Lines;
  • 5411 Grocery Stores;
  • 5552 Electric Vehicle Charging;
  • 5812 Eating Places and Restaurants;
  • 5813 Drinking Places (Alcoholic Beverages), Bars, Taverns, Cocktail Lounges, Nightclubs and Discotheques;
  • 7033 Trailer Parks and Campgrounds;
  • 7394 Equipment, Tool, Furniture and Appliance Rental;
  • 7513 Truck Rentals;
  • 7519 Motor Home and Recreational Vehicle Rentals;
  • 7523 Parking Lots, Parking Meters and Garages;
  • 7996 Amusement Parks, Carnivals, Circuses, Fortune Tellers;
  • 7999 Recreation Services.
• La cantidad de operaciones Incremental ejecutadas no está limitada.

Industry Practice Resubmission

• En caso de usar *.Pays u otro pago tokenizado en la operación original, la ejecución de la operación Resubmission es posible dentro de 14 días desde el momento de la autorización inicial.
• En caso de usar pago regular de la operación original, la ejecución de la operación Resubmission es posible dentro de 30 días desde el momento de la autorización inicial.
• El importe de la operación Resubmission debe corresponder completamente al importe del pedido original.
• Es posible la ejecución exitosa de solo una operación Resubmission.

Industry Practice Delayed Charges

• La ejecución de la operación Delayed Charges es posible dentro de 90 días desde el momento de la autorización inicial.
• La cantidad de operaciones Delayed Charges ejecutadas no está limitada.

Industry Practice Reauthorization

• En caso de usar *.Pays u otro pago tokenizado en la operación original, la ejecución de la operación Reauthorization es posible dentro de 90 días desde el momento de la preautorización inicial, excepto para Comerciantes (ver lista MCC abajo), que pueden enviar reautorización dentro de 120 días desde la fecha de la preautorización inicial:
  
  • 3351–3500 Car Rental Agencies;
  • 3501–3999 Lodging Hotels, Motels, Resorts;
  • 4411 Steamship and Cruise Lines;
  • 4457 Boat Rentals and Leasing;
  • 7011 Hotels, Motels, Resorts, Central Reservations Services (Not Elsewhere Classified);
  • 7033 Trailer Parks and Campgrounds;
  • 7394 Equipment, Tool, Furniture, and Appliance Rental and Leasing;
  • 7512 Car Rental Agencies (Not Elsewhere Classified);
  • 7513 Truck and Utility Trailer Rentals;
  • 7519 Motor Home and Recreational Vehicle Rentals;
  • 7999 Recreation Services (Not Elsewhere Classified).
• En caso de usar pago regular durante la operación original, la ejecución de la operación Reauthorization es posible dentro de 180 días desde el momento de la autorización inicial.
• El importe de la operación Reauthorization debe corresponder completamente al importe del pedido original.
• Es posible la ejecución exitosa de solo una operación Reauthorization.

Industry Practice No Show

• La ejecución es posible dentro de un año calendario desde el momento de la autorización inicial.
• La cantidad de operaciones No Show ejecutadas no está limitada.

Ejecución de cancelaciones y devoluciones

Para operaciones Industry Practice con tipo Incremental:

• El importe de la cancelación no puede exceder el importe total de la operación original y todas las operaciones Incremental relacionadas con ella.
• La suma del reembolso no puede exceder la suma total de la operación inicial y todas las operaciones Incremental relacionadas con ella.
• En caso de que previamente en la cadena transaccional con pago(s) Inremental relacionado(s) ya se haya ejecutado una cancelación parcial, entonces la suma del reembolso parcial no puede exceder el amount del pago inicial, sumado con el amount de todas las operaciones Inremental relacionadas con él, y con la deducción del amount de la(s) cancelación(es) parcial(es).
• Las cancelaciones y reembolsos para la cadena Incremental solo se pueden ejecutar por el pedido inicial. La ejecución de cancelaciones y reembolsos para pagos Incremental separados está prohibida.

La ejecución de cancelaciones y reembolsos por operaciones Industry Practice con tipo diferente de Incremental, no tienen diferencias algunas de la implementación funcional vigente - se ejecutan por separado en el marco de pedidos separados.

Verificación del portador de la tarjeta

El portador de la tarjeta puede ser verificado sin cobrar ningún pago. Para esto transmita el valor VERIFY en el bloque features de cualquier solicitud de pago.

Cuando se utiliza la función VERIFY, la tarjeta de pago será verificada para asegurarse de que es utilizada por su propietario legítimo. Si para la tarjeta está disponible 3-D Secure, entonces será ejecutada la verificación 3-D Secure. En este caso el parámetro amount de la solicitud verificadora puede ser igual solo a 0. Incluso si alguna suma de pago será transmitida en la solicitud, no será debitada de la cuenta del cliente. Después del registro exitoso el pedido inmediatamente se transfiere al estado REVERSED (cancelado).

Si la función VERIFY se transmite junto con el parámetro clientId, puede ser utilizada para crear una vinculación sin pago. Lea más detalladamente en la sección Vinculaciones.

Token Open ID

Puedes generar token Open ID. Este token puede utilizarse en lugar de las credenciales para identificar al comerciante en la pasarela de pago.

El Token Open ID no es privado, puede publicarse o integrarse en una página web. Por ejemplo, puede utilizarse cuando el pedido se realiza directamente desde el navegador. En este caso no existe riesgo de revelación de datos personales, ya que solo la pasarela de pago puede descifrar el token.

Puedes utilizar el token Open ID para autenticar al comerciante al enviar solicitudes API a la pasarela de pago. Para esto, pasa el token Open ID en el parámetro token en lugar de pasar userName y password. Puedes utilizar el parámetro token en las siguientes solicitudes:

• register.do
• registerPreAuth.do

• getOrderStatusExtended.do

• instantPayment.do

• motoPayment.do

Para generar el token Open ID, ve al panel personal, selecciona Configuraciones en el menú lateral, y luego selecciona Configuraciones generales en el bloque Comerciante. Haz clic en Crear junto al campo Token Open Id. Si ya conoces tu token, puedes ingresarlo manualmente.

Lee más aquí.

Redirección al ACS

Si se requiere 3-D Secure, entonces después de recibir la respuesta a la solicitud de pago, el cliente debe ser redirigido al ACS. Existen dos formas de redirección: regular y simplificada.

Redirección regular

Si el pago se realiza mediante 3-D Secure, los comerciantes deben redirigir a sus clientes al ACS a la dirección especificada en el parámetro acsUrl, recibido en la respuesta a la solicitud de pago. El cuerpo de la solicitud debe incluir MD=mdorder&PaReq=paReq&TermUrl=termUrl, donde:

• MD - identificador único del pedido en la pasarela de pago;
• PaReq - parámetro paReq, recibido en la respuesta a la solicitud de pago. Es un mensaje que debe ser enviado al ACS junto con la redirección y contiene los datos necesarios para la autenticación;
• TermUrl - parámetro termUrl, recibido en la respuesta a la solicitud de pago. Es la URL a la cual el ACS redirige al portador de la tarjeta después de la autenticación.

Esta debe ser una solicitud POST (no GET).

Dependiendo de la configuración acordada con el banco, el comprador después de la autenticación en el ACS será redirigido ya sea a la tienda o a la pasarela de pago.

Ejemplo de solicitud POST para redirección regular:

<html>
<head><title>ACS Redirect</title></head>
<body onload="document.forms['acs'].submit()">
ACS Redirect
<form id="acs" method="post" action="[result.acsUrl]">
    <input type="hidden" id="MD" name="MD" value="[MD]"/>
    <input type="hidden" id="PaReq" name="PaReq" value="[result.PaReq]"/>
    <input type="hidden" id="TermUrl" name="TermUrl" value="[result.TermUrl]"/>
</form>
</body>
</html>

Redirección simplificada

También la tienda en línea puede utilizar el método de pasarela acsRedirect.do, que realizará la misma redirección del portador de la tarjeta al ACS del emisor.

Pago mediante MPI/3DS Server propio

Merchant Plugin Interface (MPI)/3DS Server — es un componente de la tecnología 3D Secure, que puede ser implementado en la pasarela de pagos o en su lado. Si tiene su propio MPI/3DS Server, puede utilizarlo para la autorización autónoma 3D Secure, y en las peticiones API solo indicar el hecho de realización de tal autorización. Para habilitar esta funcionalidad, contacte con el servicio de soporte técnico.

Si utiliza su propio MPI/3DS Server, entonces en las peticiones de pago (por ejemplo, paymentOrder, paymentOrderBinding.do , o instantPayment.do) transmita parámetros adicionales en el bloque jsonParams: eci, cavv, xid, threeDSProtocolVersion y threeDsType. Estos parámetros se describen a continuación.

eci

eci — indicador de comercio electrónico (ECI), obtenido de su servidor 3-D Secure. Muestra el nivel de seguridad utilizado en el pago. Es establecido por el servidor DS según los resultados de autenticación obtenidos y de acuerdo con las peculiaridades del proceso de verificación de la tienda. El parámetro se transmite en el bloque jsonParams en formato de dos dígitos, por ejemplo, "eci": "02".

Los códigos ECI pueden diferir dependiendo del sistema de pago. A continuación se proporciona la interpretación de los códigos ECI más frecuentemente utilizados:

cavv, xid

Si el valor ECI difiere de aquellos que se utilizan para autorización SSL, también es necesario transmitir los siguientes parámetros:

• cavv - valor de autenticación del portador de la tarjeta;
• xid - identificador de transacción de autenticación 3DS del propietario de la tarjeta en el servidor 3DS (valor ARes.dsTransID, obtenido del ACS).

threeDSProtocolVersion

Además, puede pasar en la solicitud de pago el parámetro threeDSProtocolVersion (versión del protocolo 3DS). Puede tomar los siguientes valores:

• 2.1.0 - para 3DS 2
• 2.2.0 - para 3DS 2

Si no se pasa threeDSProtocolVersion en la solicitud, entonces por defecto su valor se asume igual a 2.1.0 - para 3DS 2.

threeDsType

El parámetro threeDsType (tipo de autenticación del pago) es necesario para el pago a través de su MPI/3DS Server con 3DS 2.

Para pagos con SSL este parámetro es opcional y se determina automáticamente dependiendo del valor ECI.

Ejemplo de solicitud

curl --request POST \\
  --url https://dev.bpcbt.com/payment/rest/paymentorder.do \\
  --header 'content-type: application/x-www-form-urlencoded' \\
  --data userName=test_user \\
  --data password=test_user_password \\
  --data MDORDER=0140dda0-71ed-7706-a61f-36bd00a7d8c0 \\
  --data '$PAN=4000001111111118' \\
  --data '$CVC=123' \\
  --data YYYY=2030 \\
  --data MM=12 \\
  --data 'TEXT=TEST CARDHOLDER' \\
  --data language=en \\
  --data 'jsonParams={
  "eci": "02",
  "cavv": "AkZO5XQAA0rhBxoaufa+MAABAAA=",
  "xid": "5010857f-8d3f-74e1-9c5a-54a000cc4110",
  "threeDSProtocolVersion": "2.2.0",
  "threeDsType": "5"
}'

Si utiliza su propio MPI/3DS Server, la respuesta a la correspondiente solicitud API de pago no contiene parámetros relacionados con 3D Secure, tales como redirect, termUrl, acsUrl y paReq.

Ejemplo de respuesta

{
  "redirect": "https://dev.bpcbt.com/payment/merchants/temp/finish.html?orderId=01493844-d4d3-703f-9f7e-a73900a7d8c0&lang=en",
  "info": "Your order is proceeded, redirecting...",
  "errorCode": 0
}

Gestión de cobros recurrentes

La pasarela de pagos permite configurar tareas para cobros recurrentes. Los cobros configurados posteriormente se ejecutan automáticamente de acuerdo con el cronograma establecido.

Si esta funcionalidad está habilitada para usted por nuestro grupo de soporte, puede hacer lo siguiente:

• Crear tareas recurrentes especificando datos de tarjeta y cronograma
• Editar tareas recurrentes
• Detener la ejecución de una o varias tareas
• Activar tareas recurrentes
• Excluir la ejecución de un pago específico en una tarea recurrente

Puede gestionar cobros recurrentes mediante API. Para más detalles consulte la sección API de cobros recurrentes.

Autorización 3-D Secure

Qué es 3-D Secure

3-D Secure (también llamado 3DS) - estándar técnico creado por Visa y MasterCard, que permite realizar autorización adicional del titular de la tarjeta en el lado del banco emisor. Para completar la transacción, al titular de la tarjeta se le propone confirmar su identidad mediante la introducción de una contraseña única, código SMS o PIN temporal.

El término 3DS significa 3 Domain Server. Este nombre se explica porque en cada transacción 3-D Secure participan tres partes:

1. Dominio del adquirente. Actúa como 3DS requestor – iniciador del proceso de autorización.
2. Dominio del emisor. Incluye el ACS (Access Control Server), que proporciona confirmación de identidad del pagador por el banco emisor.
3. Dominio de interacción. Actúa como enlace entre los dos primeros dominios. Como regla, es el sistema de pago.

Versiones del protocolo

La pasarela de pago soporta autorización 3-D Secure para protegerle a usted y a sus clientes de la amenaza de fraude de pago.

Para transacciones en navegador utilizamos 3-D Secure v2 (también llamado 3DS2) - versión actualizada del protocolo 3-D Secure, que proporciona mejor interacción entre los tres participantes de la transacción. El protocolo de verificación de autenticidad 3DSv2 dependiendo de la configuración del ACS del banco emisor permite realizar verificación de autenticidad sin participación del cliente (esquema Frictionless). En este caso del cliente no se requerirá realizar acciones para autenticación, tales como introducción de contraseña de un solo uso u otras acciones.

Escenarios de integración

Si la página de pago se encuentra en el lado de la pasarela de pago, el comerciante no requiere realizar ninguna acción adicional, y puede usar la API estándar de la pasarela de pago.

Si la página de pago está ubicada en el lado del comerciante, al usar autenticación del cliente por protocolo 3DSv2 para cada transacción el comerciante necesita enviar una serie de solicitudes API adicionales a la pasarela de pago.

Los esquemas de integración están descritos aquí.

Autorización 3RI

3RI – es un tipo de autorización 3DS 2, que es iniciada por el vendedor sin solicitud de confirmación de pago del titular de la tarjeta. De hecho, pago 3RI - es un pago MIT con tii=R o tii=I, es decir, pago recurrente o pago en cuotas (ver Enlaces y tipos de transacciones) con autorización 3DS 2 frictionless.

Pago recurrente 3RI o pago en cuotas es posible solo en caso de que la transacción iniciadora, en la cual se guarda el enlace, fue ejecutada con autorización 3DS 2.

Si se cumple alguna de las condiciones:

• la transacción iniciadora se ejecutaba no a través de la pasarela de pago,
• la transacción iniciadora se ejecutaba con su propio MPI/3DS Server,
• la transacción iniciadora se ejecutaba sin guardar enlace,

entonces es necesario en el bloque jsonParams enviar los siguientes parámetros adicionales: