Cómo cambiamos de pasarela de pago tres veces sin parar las ventas

Se puede cambiar de pasarela de pago con la tienda abierta y sin perder ventas. Lo difícil es saber con certeza qué se ha cobrado. En JFPro, una plataforma de sorteos con picos de un millón de visitas al día, cambiamos de pasarela de tarjeta, añadimos Bizum y al final Apple Pay, todo con la venta en marcha. Cada cambio se decidió en un día, se programó y se probó en local al día siguiente y se publicó a las 5 de la mañana, hora de España, cuando casi nadie compra.

Esto es lo que aprendimos, en el orden en que lo aprendimos.

Por qué cambiamos de pasarela

El año anterior la plataforma cobraba con Stripe. Para la edición de 2026 Stripe no nos dio la cuenta (sus condiciones excluyen los juegos de azar y las loterías), así que empezamos con el TPV virtual de Redsys a través de Banco Sabadell.

Redsys cobraba, el problema era otro. Cuando un cliente paga, Redsys avisa a tu servidor una sola vez. Si ese aviso se pierde (un corte de red, un despliegue en ese momento, un cliente que cierra la pestaña), tu sistema no sabe si la compra está pagada. La salida natural es preguntar a la pasarela por el estado del pedido, pero esa consulta por API no estaba activada en nuestra cuenta. Así que había compras que se quedaban atascadas, sin cerrar, y sin forma automática de saber si el dinero había entrado.

En una tienda normal eso es una molestia. En un sorteo, donde cada compra asigna números concretos, es un problema serio: un pago sin confirmar es un cliente que ha pagado y no tiene sus papeletas.

Antes de mirar la comisión de una pasarela, pregunta cómo se consulta el estado de un pago cuando el aviso no llega.

El cambio a Trust Payments, en dos días

Pasamos la tarjeta a Trust Payments, que tiene API para consultar cada transacción. Recibimos las credenciales de prueba un día, al siguiente estaba el flujo completo programado y probado en local, y el cambio en producción fue un ajuste en la base de datos.

Pudimos ir tan rápido por una decisión del principio, porque la pasarela de tarjeta activa es un ajuste en la base de datos y no está en el código. El backend acepta solo la pasarela seleccionada y rechaza cualquier pago que intente entrar por otra. Cambiar de pasarela es cambiar un valor, y volver atrás también.

Lo que no fue en dos días fue dejarlo fino. Durante las dos semanas siguientes ajustamos los datos de facturación que pedía la autenticación de Visa y Mastercard (el 3D Secure que obliga la normativa europea de autenticación reforzada) y añadimos la conciliación automática que contamos más abajo. Con ventas reales en marcha.

Los neobancos rechazaban la mayoría de los pagos

Con Trust apareció un problema que no tenía nada que ver con nosotros. Muchas tarjetas se rechazaban, y casi siempre después de que el cliente se identificara bien en su banco. Quien decía que no era el banco de la tarjeta.

Al cruzar los rechazos por banco emisor, el patrón era claro:

• Tarjetas de Revolut: alrededor del 72 % de los intentos rechazados.
• Trade Republic: 45 %.
• BBVA y Santander: entre el 6 y el 7 %.
• Neobancos en conjunto (Revolut, N26, bunq, Wise, Openbank, MyInvestor y otros): 61 %, frente al 11 % del resto.

Casi todos eran rechazos firmes, así que reintentar con la misma tarjeta no servía.

Cambiar otra vez de pasarela de tarjeta no lo iba a arreglar, hacía falta otro método de pago. Añadimos Bizum, que va por el mismo TPV de Sabadell, se programó en un día y se activó a las 5 de la mañana siguiente. Desde entonces, casi la mitad de las compras se pagan con Bizum, y se rechaza bastante menos que la tarjeta (entre el 10 y el 15 % de las compras, frente al 16 a 27 % de la tarjeta según la semana). Al final añadimos también Apple Pay a través de Trust.

Cómo no perder un pago

Con tres métodos de pago y picos de más de 30.000 peticiones por hora, la pregunta de cada minuto es la misma: ¿esta compra está pagada o no? Lo resolvimos con cuatro capas.

1. Dos vías de confirmación. El aviso de servidor a servidor de la pasarela y, si se pierde, la respuesta firmada que vuelve con el cliente al terminar el pago. Cualquiera de las dos cierra la compra, y en las dos comprobamos la firma, la referencia y el importe antes de dar nada por pagado.

2. Avisos que se pueden recibir dos veces. Marcar una compra como pagada solo hace algo si seguía sin pagar, dentro de una transacción con la fila bloqueada. Si el mismo aviso llega dos o diez veces, no pasa nada.

3. Conciliación automática. Cada pocos minutos se repasan las compras pendientes, cada hora se cruzan con la API de Trust, y si una compra de Bizum se queda atascada, el sistema pregunta a Sabadell antes de darla por perdida. Si consta pagada, se rescata y se asignan las papeletas. Si el banco no responde, se espera hasta 24 horas.

4. Ante la duda, a mano. Si la firma no cuadra pero la pasarela dice que cobró, la compra no se marca como pagada sola: se abre un aviso interno para revisarlo. Preferimos que un cliente espere diez minutos a regalar papeletas.

Las papeletas siguen la misma lógica. Los números libres están en un pool, se asignan al confirmar el pago, y cada hora se comprueba que vendidos más libres sumen exactamente el total del sorteo.

Los cobros dobles

Los hubo, pocos: menos de uno de cada mil pagos con tarjeta. La causa era un reintento en un momento de lentitud que lanzaba dos autorizaciones para la misma compra. Una tarea los detecta cada seis horas, devolvemos el cobro que sobra y escribimos al cliente antes de que tenga que reclamar.

La forma de evitarlos desde el principio es enviar una clave única por compra en cada autorización (lo que Stripe llama clave de idempotencia), para que la pasarela reconozca un reintento y no cobre dos veces, y bloquear el botón de pagar hasta tener respuesta. Si tu pasarela lo permite, ponlo antes de la primera venta.

Lo que haríamos igual y lo que cambiaríamos

Haríamos igual:

• La pasarela activa como un ajuste, para cambiarla en minutos y volver atrás igual de rápido.
• Los cambios a las 5 de la mañana, con un plan para deshacerlos.
• La conciliación diaria contra cada pasarela desde el primer día de venta.

Cambiaríamos:

• Preguntar por la API de consulta de estado antes de firmar con una pasarela.
• Lanzar con Bizum ya activo. En un producto que mucha gente paga con tarjetas de neobancos, los rechazos eran previsibles.
• Clave contra el cobro doble en cada autorización desde la primera venta.
• Que el sistema no diga "devuelto" hasta que el banco lo confirme. En Redsys y Bizum las devoluciones se hacen en el panel del banco, y una devolución marcada pero no hecha es un cliente que se enfada con razón.

En resumen

• Antes de firmar con una pasarela, comprueba cómo se consulta un pago cuando el aviso no llega.
• Haz que la pasarela activa sea un ajuste y el cambio será de minutos.
• Si tus clientes usan neobancos, mira el rechazo por banco emisor y ofrece Bizum.
• Confirma por dos vías, acepta avisos repetidos sin efecto y concilia cada hora.
• Evita cobros dobles con una clave única por compra.
• Publica los cambios cuando nadie compra y con el camino de vuelta preparado.

Si vas a cambiar de pasarela, o tus pagos se quedan sin confirmar y no sabes por qué, cuéntanos qué tienes. Te decimos qué revisar primero y cuánto cuesta.