Integración de la pasarela de pagos Adyen en IBM WebSphere Commerce

Transcripción

1 Enero 2014 Ángel Infante Yter Jefe de proyectos en atsistemas Integración de la pasarela de pagos Adyen en La pasarela de pago Adyen conecta con más de 200 métodos de pago distribuidos en América del Norte, América Latina, Europa, Asia Oriental y Oceanía. Incluye desde tarjetas de crédito internacionales hasta métodos de pago locales basados en efectivo. Adyen no sólo se encarga de procesar los pagos sino que, además, proporciona todos los métodos a través de una única solución. La integración de Adyen es extremadamente flexible, permitiendo externalizar completamente la gestión de los datos de pago y su seguridad, cumpliendo los estándares de la normativa PCI (Payment Card Industry); o capturar los datos en el sistema de comercio electrónico, mediante, siempre y cuando la empresa cumpla los estándares PCI. Para ello, Adyen pone a disposición de sus clientes una versión Hosted Payment, donde el usuario interactúa con pantallas proporcionadas por Adyen hasta que la plataforma de comercio electrónico recibe la confirmación; y una API (Interfaz de Programación de Aplicaciones), mediante la cual se puede gestionar la transacción completa en la plataforma de comercio electrónico. La experiencia de atsistemas en la integración de Adyen se demuestra mediante el caso concreto expuesto en este documento, donde se explica su integración con mediante un plugin de pago desarrollado a tales efectos. Además del plugin Adyen para WebSphere, en atsistemas hemos desarrollado plugins para integrar las siguientes pasarelas de pago: Saferpay, PayPal, Klarna, y Gift Card. Funcionalidad Dentro de este proceso de integración, no interesa centrarse sólo en la realización del pago mediante el plugin desarrollado, sino llegar a integrar tres sistemas a la vez, en el proceso de integración: WebSphere : delega el pago a Adyen, recibe la confirmación e informa al ERP que el pedido ha sido completado. Adyen: interactúa en modalidad Hosted Payment con el usuario para recoger los datos de pago y completar el proceso. Notifica al plugin de pago sobre los cambios de estado en el pago, principalmente autorización y posterior captura - el importe ha sido retirado realmente de la cuenta del usuario. ERP: se comunica con el plugin de pago para comprobar la captura, y aprueba el pedido para que sea enviado al cliente.

2 Integración de la pasarela de pagos Adyen en El siguiente diagrama ilustra las interacciones entre los tres sistemas implicados: Websphere Frontend Backend Adyen payment plugin Checkout Send Order Open Hosted Payment Page Notification Status Check ERP USER Payment Adyen Frontend Backend Capture Request Para ir sustituyendo, gradualmente, un método de pago en uso por uno soportado a través de Adyen, es necesario un sistema de distribución de peticiones entre ambos métodos. Gestión de Riesgos La incorporación de un nuevo método de pago siempre implica ciertos riesgos para la correcta gestión de los pedidos. En caso de que Adyen esté destinado a sustituir un método de pago en uso, funcionando correctamente durante un periodo de tiempo considerable, una buena medida preventiva consiste en incorporar de forma incremental la nueva pasarela, empezando a dar servicio a un pequeño grupo de usuarios, e incrementando el alcance hasta cubrir el 100% de los pedidos. Para poder acometer este enfoque incremental, es necesario un sistema de distribución de peticiones entre el método de pago anterior y Adyen. Dado que un sistema aleatorio que mostrase una u otra pasarela de pago alternativamente sería desconcertante para el usuario, el sistema debe garantizar que un mismo usuario siempre visualice la misma pasarela para un método de pago concreto. Una buena estrategia consiste en establecer un valor porcentual configurado en el sistema; y que sólo los usuarios con los dos últimos dígitos de su identificador por debajo del porcentaje configurado, puedan realizar el pago mediante la nueva pasarela. El plugin desarrollado implementa esta estrategia.

3 Integración de la pasarela de pagos Adyen en Arquitectura Para lograr acometer la integración descrita en el apartado anterior, el desarrollo realizado se divide realmente en dos subsistemas: Plugin de pago para WebSphere, que delega la información de los datos de pago a Adyen. Servicios Web responsables de recibir las notificaciones de Adyen y consultas de estado del ERP. Aunque los servicios web podrían estar alojados en un servidor distinto, en el caso que nos ocupa los servicios se desarrollaron dentro del propio WebSphere, como un módulo más de su arquitectura. Estructura de Paquetes El plugin desarrollado está formado por los siguientes paquetes: com.merce.store.checkout.command: comandos que gestionan los datos de la sesión del pago y muestran la página de pago de Adyen. com.merce.orders.command: comandos que procesan el pago. Realizan la invocación del plugin de pago y cierran la pantalla de Adyen para mostrar la página de confirmación de WebSphere. com.merce.adyen.notification.object: Entity Beans para persistir las notificaciones en la base de datos. com.merce.adyen.notification.service: WebService Javabeans, cuya estructura corresponde al WSDL de Adyen. Plugin de pago El plugin para Adyen cumple con las especificaciones de WebSphere. El siguiente diagrama describe el flujo de pago gestionado por el plugin en modalidad Hosted Payment: UI Controller AdyenPlugin Adyen :Checkout openpaymentframe USER :DoPayment popup result :orderprocess :confirm :approve :confirmationpage

4 Integración de la pasarela de pagos Adyen en Servicios Web Los Servicios Web desarrollados son responsables de recibir las notificaciones de Adyen, e informar del estado del pago al ERP. Recepción de Notificaciones Todas las notificaciones se almacenan en una tabla a medida para su posterior consulta desde el ERP, o para fines estadísticos. Adyen ofrece dos alternativas para recibir sus notificaciones: Servicios Web SOAP Servicios Web HTTP+XML La diferencia entre ambos enfoques radica en el encapsulado SOAP y en el descriptor WSDL, que permite validar la estructura de los datos. Por estos motivos, SOAP fue la alternativa seleccionada. A continuación, se muestra la estructura de la tabla en la que el servicio almacena las notificaciones recibidas: Column Name Column Type Column Type Lenght Column Constraints ID ADYEN NOTIFICATION NUMBER 20 PRIMARY KEY RECEPTION DATE DATE NOT NULL LIVE NUMBER 1 EVENTCODE VARCHAR2 30 PSP_REFERENCE VARCHAR2 100 NOT_NULL, INDEXED NOT UNIQUE ORIGINAL REFERENCE VARCHAR2 100 MERCHANT REFERENCE VARCHAR2 100 MERCHANT ACCOUNTCODE VARCHAR2 250 EVENT DATE DATE SUCCESS NUMBER 1 PAYMENT METHOD VARCHAR2 50 OPERATIONS VARCHAR CURRENCY CHAR 3 AMOUNT NUMBER 20 SCORING NUMBER 20 SCORING RULES HIT VARCHAR 255 REASON VARCHAR2 255

5 Herramienta de traducción de catálogo para Información del Fraude La estructura de las notificaciones de Adyen es muy rigurosa, excepto en un punto: el mapa de datos adicionales. El contenido indefinido de este mapa aporta mayor flexibilidad a Adyen, y fue uno de los puntos que presentaron mayores dificultades en tiempo de análisis. Justamente en este mapa es donde se encuentra la información relativa al fraude. El mapa de datos en el que se informa el fraude contiene un conjunto de controles de fraude aplicados y la puntuación total de fraude. Todos los identificadores de los controles de fraude contienen el prefijo fraudcheck-*, mientras que la puntuación total de fraude viene informada con el identificador totalfraudscore. <additionaldata> <entry> <string>fraudcheck-1-paymentdetailreferral</string> <string>0</string> </entry> <entry> <string>fraudcheck-3-paymentdetailusage</string> <string>0</string> </entry> <entry> <string>totalfraudscore</string> <string>51</string> </entry> Los controles de fraude con valor mayor a 0, se almacenan en el campo SCORING_RULES_HIT. Información de Estado Este servicio web publica una operación llamada checkadyenstatus cuya firma es: <String outcome,string reason> checkadyenstatus (String PSPReference, String operation) Esta operación recibe el PSPRefrence, que es el identificador de pago de Adyen; y una cadena que informa la operación a realizar - PAYMENT o REFUND -. Cuando el servicio es invocado, éste busca el resultado de la última operación de Devolución o Captura, entre todas las filas de la tabla ADYEN_NOTIFICATIONS cuyo campo PSP_REFERENCE coincide con el valor pasado por parámetro. El resultado puede ser SUCCESS, FAILED o NOT FOUND.

6 En atsistemas somos más de 500 profesionales dedicados desde 1994 a la consultoría, servicios de IT y desarrollo de software. Nuestros servicios se caracterizan por la flexibilidad y la agilidad, lo que nos permite ayudar a grandes empresas de todos los sectores, aportando conocimiento y experiencia sobre el más amplio abanico de tecnologías. Nuestra cartera de clientes incluye más de 200 de las principales empresas del país, con representación de todos los sectores de actividad, a los que prestamos servicio desde nuestras oficinas de Madrid, Barcelona, Cádiz y Zaragoza. Nuestro portfolio de servicios abarca desde el desarrollo de software a medida hasta la integración de grandes soluciones de software empresarial, en áreas que van desde la más compleja arquitectura de sistemas hasta las soluciones más novedosas de comercio electrónico o aplicaciones móviles. Valle de Alcudia, Las Rozas, Madrid Passeig de Gràcia 55, 8º - 4ª Barcelona info@