BankStore IFRAME

Integración Full Screen / Iframe

  1. Introducción
  2. Integración para la captura de datos
    1. Operativa de captura de datos (ejemplo)
    2. Modalidades de cobro en función a la integración
  3. Parámetros
    1. Ejecución de Alta de Usuario en el sistema (add_user)
    2. Ejecución de Cobro (Alta implícita de Usuario en el sistema) (execute_purchase)
    3. Ejecución de Alta de Suscripción (Alta implícita de Usuario en el sistema) (create_subscription)
    4. Ejecución de Alta de Preautorización (Alta Implícita de Usuario en el sistema) (create_preauthorization)
    5. Validación de tarjeta y confirmación (alta implícita de usuario en el sistema) (deferred_preauthorization)
    6. Ejecución de cobro a Usuario en el sistema por DCC (execute_purchase_dcc)

Introducción

La finalidad de utilizar una integración para la captación de los datos de tarjeta del cliente, es facilitar el cumplimiento de la norma PCI-DSS de la aplicación web. De esta forma la recogida de los datos bancarios se realiza en el entorno seguro de Banco Sabadell para posteriormente tratarlos en una conversación Server2Server sin riesgo de robo de datos.

Integración para la captura de datos

Esta solución permite la generación de un formulario de captura de datos con el look&feel predefinido en el panel de control del producto. Esta solución debe ser activada por Banco Sabadell, por lo que si no aparece en el panel de control, deberás solicitarlo mediante la apertura de un ticket administrativo (Soporte → Notificación de incidencia → Departamento administrativo).

En esta sección podrás ver una previsualización de los estilos aplicados más abajo. Los estilos permiten la referencia a sites externos pero deberán responder con un certificado digital correctamente firmado por una entidad de confianza, de lo contrario el navegador del cliente mostrará un error que creará desconfianza en su cliente:

En la sección de la configuración del producto, justo debajo de la previsualización, encontrarás los parámetros que son modificables desde el panel:

Estos serán parametrizables mediante propiedades CSS para ajustarse al diseño de tu aplicación.

Si las propiedades disponibles no se ajustan a las necesidades de la aplicación, es posible solicitar un desarrollo de “Template” específico mediante la apertura de un ticket administrativo (Soporte → Notificación de incidencia → Departamento administrativo).

Te informaremos de los pasos a seguir y la normativa de dicho desarrollo.

Las funcionalidades disponibles en Bankstore IFRAME son:

  • Función: (add_user)
  • Función: (execute_purchase)
  • Función: (create_subscription)
  • Función: (create_preauthorization)
  • Función: (deferred_preauthorization)
  • Función: (execute_purchase_dcc)

Dichas funcionalidades son las que implican la recogida de los datos bancarios del cliente. De forma posterior, una vez recogidos los datos IDUSER y TOKENUSER, se podrán utilizar las integraciones XML y REST para ejecutar compras, modificación de las suscripciones, información de los datos de tarjeta del usuario, cancelación de suscripciones, etc...

Operativa de captura de datos (ejemplo)

La finalidad de utilizar una integración para la captación de los datos de tarjeta del cliente, es facilitar el cumplimiento de la norma PCI-DSS de la aplicación web. De esta forma la recogida de los datos bancarios se realiza en el entorno seguro de Banco Sabadell para posteriormente tratarlos en una conversación Server2Server sin riesgo de datos susceptibles de robo

En un entorno ficticio encontraríamos el siguiente escenario:

Un comercio con alta recurrencia quiere almacenar los datos bancarios del cliente para facilitar las compras futuras. La técnica de la recogida de sus datos bancarios son dos:

  • Desde la cuenta de cliente. En su panel de control puede modificar sus datos de facturación, envío e incluso sus tarjetas de crédito/débito asociadas. De esta forma al finalizar el carrito de compra, con sólo pulsar un botón realizará el pago del pedido
  • En la primera compra. El cliente introduce todos sus datos bancarios en el proceso final del carrito de compra y quedarán almacenados para compras futuras. De esta forma, elalmacenamiento se realiza de una forma “transparente” al finalizar su pedido.

En el primer caso, el cliente se autentica en la plataforma del e-commerce porque es un usuario previamente dado de alta. Entra en su panel de control y elige añadir una tarjeta de crédito/débito a su cuenta para realizar los pagos. El comercio muestra de una forma integrada en su panel de control, un formulario de captura de datos y Banco Sabadell notifica al comercio del resultado. El comercio almacena los datos IDUSER y TOKENUSER a la cuenta del cliente (puede tener varios, para disponer de varias tarjetas), para posteriormente realizar los cobros.

El cliente introduce los datos en el formulario de captura de datos de Banco Sabadell (integrado estéticamente con la web del comercio) y Banco Sabadell notifica en diferido los datos IDUSER y TOKENUSER en caso de éxito.

El comercio almacena los datos asociados a la cuenta de su cliente para poder ejecutar un cobro mediante una integración SOAP XML

En el segundo caso (almacenamiento en la primera compra), el cliente realiza el pedido normalmente y en la selección del método de pago por tarjeta de crédito/débito le solicita los datos bancarios para proceder al pago.

Los datos bancarios los introduce en un formulario de captura de datos generado por Banco Sabadell devolviendo tanto los datos del almacenamiento del usuario (IDUSER y TOKENUSER) como el resultado de la transacción

Este caso sólo se produce si el comercio no dispone de los dos datos IDUSER y TOKENUSER. En caso contrario la comunicación no se haría mediante un formulario de captura de datos.

En la situación que el comercio disponga de los datos IDUSER y TOKENUSER, ya bien por la obtención mediante un add_user, el cliente ha introducido sus datos desde su panel de control del comercio, o mediante execute_purchase, el cliente ya ha realizado una compra con anterioridad, el método para realizar una compra es diferente. El método a utilizar será mediante una conexión Server2Server (XML or REST) donde el comercio utilizará el servicio execute_purchase de forma directa con Banco Sabadell.

Se recomienda utilizar algún tipo de autenticación (tipo PIN o similar) para ejecutar el servicio de execute_purchase para evitar compras no solicitadas.

Dichas compras no solicitadas suelen ser motivo de disputa de la operación pudiendo incurrir en gastos adicionales por parte de la entidad bancaria y si se trata de una falta reiterada, se podría llegar a cancelar la cuenta.

Parámetros

Ejecución de Alta de Usuario en el sistema

Función: (add_user)

Esta operación dará de alta un nuevo usuario en el sistema y realizará la notificación correspondiente.

A continuación, selecciona el tipo de integración:

REST GET

Ejecución de Cobro (Alta implícita de Usuario en el sistema)

Función: (execute_purchase)

Esta operación dará de alta un nuevo usuario en el sistema y realizará la operación de cobro sobre ese usuario. Se notificará del resultado del alta de usuario y la operación de cobro.

A continuación, selecciona el tipo de integración:

REST GET

Ejecución de Alta de Suscripción (Alta implícita de Usuario en el sistema)

Función: (create_subscription)

El alta de una subscripción implica el alta de un usuario en el sistema BankStore de Banco Sabadell. Esta operación dará de alta un nuevo usuario en el sistema y realizará la operación del primer cobro de la suscripción. Se notificará del resultado de la suscripción.

A continuación, selecciona el tipo de integración:

REST GET

Ejecución de Alta de Preautorización (Alta Implícita de Usuario en el sistema)

Función: (create_preauthorization)

Esta operación dará de alta un nuevo usuario en el sistema y realizará la operación de alta de preautorización. Se notificará del resultado del alta de usuario y la operación de preautorización.

A continuación, selecciona el tipo de integración:

REST GET

Validación de tarjeta y confirmación (alta implícita de usuario en el sistema)

Función: (deferred_preauthorization)

Este tipo de operacion permite al comercio validar si los datos de tarjeta introducidos son correctos. En esta validacion se realiza la autenticacion del titular salvo que el comercio no posea metodo de pago seguro (Tipo 13). Para utilizarlo en la rest se trata de llamar a preatuh para verificar la tarjeta con los datos del pago y confirmpreauth para completarlo, con el parámetro deferred=1 en ambos caso. Para utilizarlo en GET hay que llamar a deferred_preauthorization y deferred_preauthorization_confirm análogamente.

A continuación, selecciona el tipo de integración:

REST GET

Ejecución de cobro a Usuario en el sistema por DCC

Función: (execute_purchase_dcc)

A continuación, selecciona el tipo de integración:

REST GET

¿Tienes alguna duda que no queda resuelta?

Entra en el panel de control de tu cuenta y abre un ticket.

Entra en tu panel