Cómo solucionar la caída de Redsys del 18

La caída de Redsys del 18 de noviembre ha hecho mucho daño a muchos merchants. Toda españa vieron paralizado su negocio al no poder aceptar pagos con tarjeta. En este artículo, vamos a ver qué alternativas tenemos como merchant ante una eventual caída del adquirente/procesador.

«En medio de la dificultad, reside la oportunidad.»
Albert Einstein.

Antes de nada, desear que Redsys, encuentre cuanto antes la causa raíz del problema que tuvieron el pasado día 18. No es plato de buen gusto para nadie cuando algo así ocurre.

Esto demuestra que todos, absolutamente todos los proveedores de tecnología que tienen elementos de comunicaciones como una de las claves del negocio, están expuestos ante cualquier incidencia, problemas de latencia, cuellos de botella, caídas de servidores, etc. Todos.

Aquellos que somos motoristas, tenemos una frase para definir esto y, es que sólo existen dos tipos de motoristas: los que se han caído y los que se van a caer.

Pues en tecnología es lo mismo, sólo hay dos posibles situaciones: caídas pasadas o caídas futuras. Recordemos por ejemplo el caso de Square, que por un problema con las DNSs estuvo más de 14h sin poder procesar pagos.

Ya he leído algunos comentarios interesantes en los que algunos dicen: mi plataforma no se cae, tiene una disponibilidad psicodélico-maravillosa y no tenemos estos problemas. Es posible que por ahora no hayan ocurrido, pero tarde o temprano, a todos nos pasa.

También he leído que con Bitcoin esto no pasa. Es posible, pero BTC no permite el cálculo económico.

Perfecto, Marcos, pero ¿qué hacemos ante estas eventualidades?

Os cuento, pero como siempre, mi disclaimer habitual:

Disclaimer: todas las opiniones y declaraciones vertidas en este blog, representan únicamente mis opiniones y para nada vinculan a ninguna entidad, empresa, o negocio con quien tenga cualquier tipo de relación o colaboración

La caída de Redsys del 18 de noviembre

La caída de Redsys provocó reacciones de todo tipo en redes sociales y en los principales medios de prensa del país.

Huelga decir que el servicio que prestamos los que nos dedicamos a los pagos, se puede definir como un servicio algo ingrato, dado que se presume que siempre debe funcionar y, cuando no funciona, cualquiera que sea el motivo, evoca los sentimientos negativos más profundos en nuestro ser, como consumidores y como merchant.

No puedes pagar con tarjeta y no llevas efectivo encima. La solución rápida sería llevar efectivo encima, sin duda, pero no fue tampoco una solución en el día de ayer cuando los cajeros automáticos bancarios tampoco funcionaban. Habría que ver si los cajeros de Euro Automatic Cash o Euronet funcionaban, cosa que desconozco a fecha de hoy.

Desde el lado del consumidor o merchant, ya sabemos la solución rápida que es el efectivo, pero, como merchant, ¿qué otras opciones nos quedan para continuar aceptando pagos con tarjeta en el caso de sufrir un problema como el de la caída de Redsys del 18 de noviembre? Veámoslos.

Qué partes están implicadas en un pago

Haciendo un breve repaso a quién tenemos involucrados en un proceso de pago, como expuse en este artículo y este otro artículo, en un pago tradicional, como ya sabemos tenemos a las siguientes partes de manera muy muy resumida:

• Banco Emisor
• Pasarela de pago
• Banco Adquirente
• Esquemas

El cliente final introduce la tarjeta en el terminal de pago (o la acerca mediante EMV Contactless). Esa tarjeta está emitida por el banco emisor del cliente final. Aquí se produce la primera interacción.

El terminal de pago, lee los datos de la tarjeta, los cifra y manda la transacción del importe que sea (pongamos 100€) a través de la pasarela de pago al banco adquirente del merchant.

El banco adquirente manda la transacción a los esquemas, VISA y Mastercard y estos se encargan de lanzarla al banco emisor de la tarjeta para recibir el OK o KO a la misma.

Posteriormente, la transacción viaja con el resultado de la aceptación al terminal de pago para decir si la transacción ha tenido lugar o no.

En este sentido, el esquema que tienen montados los bancos de España, omite uno de los pasos, actuando Redsys como esquema local sin necesidad de subir la transacción a VISA o Mastercard para aceptarla. Son los sistemas de Redsys los que se encargan de hacer de plataforma para el adquirente y el emisor en España para determinar si una transacción puede ser aceptada o no.

Esto es grosso modo lo que ocurre durante un proceso de pago.

Dónde pueden ocurrir los fallos en un proceso de pago

Fundamentalmente los problemas que pueden ocurrir son de comunicaciones. En cada uno de los nodos, puede haber una interrupción de la comunicación y no producirse el procesamiento del pago.

La caída de Redsys, según nos comentan, tuvo que ver con líneas de comunicación interna:

Informamos que están solventadas las degradaciones de servicio de pagos de la última hora, exclusivamente vinculadas a las líneas de comunicación interna.

— Redsys (@Redsys_es) November 18, 2023

Siempre, siempre tiene que ver con problemas de comunicaciones: del terminal a la pasarela, de la pasarela al adquirente, del adquirente a los esquemas, de los esquemas a los emisores, o, incluso, del terminal a la propia red interna de la tienda del merchant.

Entonces, según el dónde esté el problema ¿dónde podemos incidir?

Los distintos backups que podemos utilizar

A continuación, analizamos los distintos casos que podemos tener de interrupción de la comunicación y qué medidas de protección podemos poner para seguir aceptando pagos con tarjeta.

Si nos fallan las comunicaciones de la tienda (I)

En el caso de que no tengamos red en la tienda (entendamos tienda en el sentido más amplio), tenemos una capacidad que la mayor parte de las pasarelas de pago permiten una configuración de transacciones Offline.

Dichas transacciones tienen lugar cuando el terminal y la tarjeta del emisor resuelven la transacción de manera autónoma sin necesidad de lanzar la transacción para ser aprobada online.

Esas transacciones cumplen a la perfección con la normativa y los requisitos de PCI. Una vez el terminal de pago reestablece la comunicación con el exterior, lanza todas las transacciones que el mismo almacena en la memoria para su posterior aprobación.

Este modo es enteramente configurable por el merchant, determinando cuál es el tiempo que debe esperar hasta entrar en modo offline y cuántos intentos debe hacer hasta determinar que no es posible la comunicación.

Estas transacciones implican que el adquirente los está procesando en tiempo real. Es decir, que no hay una aprobación ni una verificación de los fondos en tiempo real. Esto significa que el merchant corre con el riesgo de un eventual rechazo de la transacción por el adquirente.

Para ello, los merchant suelen establecer ciertos límites para cada transacción que se procese en modo offline.

Como podréis sobreentender, el modo offline permite al negocio seguir procesando un volumen elevado de transacciones que, en algún caso, puede llegar a ser superior el 50-60% de las transacciones.

Si nos fallan las comunicaciones de la tienda (II)

La segunda parte tiene que ver con el acceso a internet de manera remota.

Por ir al grano, se trata de tener terminales de movilidad, es decir, que usen capacidades de conexión móvil en vez de comunicaciones de red tradicional de la tienda para establecer comunicación con la pasarela.

Estos terminales pueden estar perfectamente integrados con el sistema de caja y recibir la petición de cobro directamente de este para cobrar como el resto de terminales fijos y no actuar como un terminal en modo stand alone (terminal sin integración con sistema de caja).

Estos terminales utilizarían la red 4G – 5G para lanzar las transacciones y tener una aprobación online del adquirente.

Otra alternativa de movilidad es utilizar tecnología SoftPOS para continuar aceptando pagos en caso de que la red de la tienda no esté disponible.

Si nos falla el banco adquirente

Este es el caso que hemos vivido con la caída de Redsys del pasado día 18 de noviembre. La comunicación con el adquirente no se puede producir porque está indisponible.

Para entender aquí el papel de Redsys, esta compañía es una empresa participada por la mayor parte de los bancos de España para externalizar los servicios tecnológicos de adquirencia y tener un procesador único para la interconexión bancaria. ¡Boom!

En este sentido, la caída de Redsys del día 18 de noviembre, supuso que no era posible procesar pagos cuando tu adquirente formaba parte del entramado de sociedades que pertenecen a Redsys.

¿Qué hacemos entonces cuando el adquirente no está disponible?

Sencillo: enrutar a otro adquirente.

– Es que es más caro – diréis algunos que os dedicáis a esto de los pagos.
Mi respuesta: – es más caro ingresar 0€ durante un periodo de 1-2h un sábado que pagar un porcentaje pequeño del pago –

Hagamos un sencillo ejercicio:

Pongamos que, en una tienda, por ejemplo un supermercado, un sábado a las 12 de la mañana, en cada hora hay 1.000 compradores. Cada uno va a hacer una compra media de 150€. Son 150.000€ de ventas.

Si no hay adquirente alternativo, no se procesan 150.000€ a la hora. Si son 2h, se pierden 300.000€ de venta.

Vamos a suponer que el adquirente local tiene una tasa de descuento del 0.30% del pago. Poniendo un sobrecoste del doble de tasa de descuento entre un adquirente local y uno alternativo que procese cross-border (aquí explico lo que es la adquirencia cross-border), nos vamos a una tasa del 0.60%*.

Procesar esos 300.000€ con un adquirente alternativo nos ha costado 1.800€. Es decir, facturamos 298.200€.

Frente a los 0€ que ingresamos si no tenemos adquirente alternativo, yo lo veo. ¿Y vosotros?

Para esto, necesitamos que la pasarela de pago que usemos sea capaz de ejecutar un multienrutamiento a distintos adquirentes. Esta capacidad de poder disponer de un fallback acquiring no todas las pasarelas las tienen. Por tanto, es fundamental que el PSP que tengamos como proveedor tenga una capacidad como esta para poder asegurarnos que el pago seguirá funcionando ante una eventual caída del adquirente.

*Tasa de descuento totalmente aleatorias y cogidas para realizar el business case. Cualquier parecido con la realidad es pura coincidencia. Las tasas de descuento de adquirencia suelen presentarse bajo el modelo ICH++ en el que los costes del intercambio bancario y del esquema son totalmente variables dependiendo de la tarjeta que se use para realizar el pago.

Resumen para prevenir caídas como la de Redsys del 18 de noviembre

Las distintas entidades con las que un merchant tiene contrato, generalmente son:

• Proveedor de internet
• PSP
• Adquirente

Si fallan cualquier de estos siempre podremos por tanto emplear medidas de backup para continuar aceptando pagos y no tener pérdidas en el negocio por falta de comunicaciones con cualquiera de los actores involucrados.

Por tanto, si eres parte interesada, te recomiendo que hables con tu proveedor de pagos y empieces a emplear medidas de backup que te permitan continuar con el negocio funcionando y las caídas queden como bonitas anécdotas de lo que pudo salir mal pero al final no.

Una caída como la de Redsys del 18 de noviembre hace muy necesario que, como merchant, se planteen estos distintos escenarios. Especialmente en estas épocas en las que estamos donde cada venta cuenta. Mucho.

Y si tienes dudas, contacta conmigo, seguro que puedo ayudarte a emplear esas medidas de backup.

Gracias por leerme, gracias por tu tiempo.

Retail&Payments