GOV.UK cambia de Stripe a Adyen

GOV.UK cambió Stripe por Adyen y, aunque a primera vista parece solo un ajuste de proveedor, el movimiento dice bastante más. Cuando una plataforma pública del tamaño de GOV.UK toca su capa de pagos, no lo hace por capricho: lo hace porque hay presión por costos, por continuidad operativa y por control sobre una pieza que, si falla, frena trámites reales.

La noticia importa más allá del Reino Unido. Si trabajas en producto, pagos o infraestructura, este tipo de cambio te da una pista útil: el proveedor de checkout no es solo una decisión técnica, también es una decisión de operación y de soberanía. Y en servicios públicos, donde el margen para errores es bajo, esa mezcla pesa todavía más.

Qué cambió exactamente en GOV.UK

Según la nota de The Register, GOV.UK reemplazó Stripe por el proveedor neerlandés Adyen para sus pagos. No estamos hablando de una app pequeña probando un checkout nuevo, sino de una plataforma estatal que procesa cobros vinculados a servicios públicos. Cuando el cambio ocurre ahí, el mensaje es claro: el stack de pagos debe soportar volumen, disponibilidad y reglas de gobierno más estrictas que las de un e-commerce promedio.

La diferencia entre Stripe y Adyen no es solo de marca. Stripe suele ser muy fuerte en velocidad de integración, experiencia de desarrollador y time-to-market. Adyen, por su parte, suele venderse mejor en escenarios enterprise, con cobertura omnicanal, más control operativo y una arquitectura pensada para grandes volúmenes y múltiples regiones. No significa que uno sea “mejor” en abstracto; significa que el contexto decide.

En un portal gubernamental, la pregunta no es “¿cuál tiene más SDKs?”. La pregunta real es: ¿cuánto cuesta cada transacción?, ¿qué pasa si un proveedor cae?, ¿cómo se reconcilian pagos con sistemas internos?, ¿puedo cambiar reglas sin rehacer medio backend?, ¿qué tanto dependo de una sola plataforma para cobrar? Ahí es donde esta migración se vuelve interesante.

Lo que sí puedes leer entre líneas

No tenemos acceso aquí a los números internos de GOV.UK, así que no conviene inventar ahorros ni porcentajes. Pero sí podemos leer patrones. Cuando una organización pública cambia de procesador, normalmente está persiguiendo una combinación de estos objetivos:

1. Reducir costo total de operación, no solo la comisión visible por transacción.
2. Mejorar resiliencia con mejores rutas de pago, soporte y mecanismos de failover.
3. Ganar control sobre la relación con adquirentes, métodos de pago y conciliación.
4. Evitar dependencia excesiva de una sola empresa para una función crítica.

Eso no es teoría. Es el tipo de conversación que ocurre cuando una plataforma ya no está optimizando solo conversión, sino continuidad del servicio.

Costos: la comisión visible no es el costo real

La mayoría de equipos mira primero la tarifa por transacción. Tiene sentido, porque es el número más fácil de comparar. Pero si gestionas pagos a escala, sabes que ese dato por sí solo engaña bastante. El costo real incluye contracargos, soporte, conciliación, incidencias, retenciones, tiempos de liquidación y el trabajo interno que te obliga a hacer cada proveedor.

Imagina una plataforma que procesa 1 millón de pagos al mes. Si la diferencia efectiva entre proveedores fuera de apenas 0,15 puntos porcentuales en el costo total, ya no estás hablando de centavos aislados, sino de una cifra anual muy seria. No hace falta conocer el número exacto de GOV.UK para entender el incentivo: a gran escala, pequeñas diferencias se convierten en presupuesto.

Además, el costo también depende de la operación. Si un proveedor te obliga a construir más lógica propia para conciliación o excepciones, ese trabajo termina en horas de ingeniería y soporte. En cambio, si el proveedor ofrece mejores herramientas de reporting, reconciliación y control de flujos, puedes bajar el costo interno aunque la tarifa nominal no parezca la más baja.

Coste total de propiedad, no solo fee por transacción

Cuando evalúes un procesador, pon la conversación en estos términos:

• comisión por transacción
• costo de liquidación y tiempos de payout
• costo de soporte y gestión de incidencias
• horas de ingeniería para integración y mantenimiento
• complejidad de conciliación contable
• impacto de fallos en conversión y SLA

Ese enfoque cambia la conversación. Un proveedor con una tarifa ligeramente más alta puede salir más barato si reduce fricción operativa y baja el volumen de tickets internos. Y al revés, una tarifa agresiva puede salir cara si el equipo termina creando parches para todo.

Aquí conviene revisar documentación oficial de ambos proveedores antes de tomar decisiones. Stripe publica su documentación de pagos y webhooks en Stripe Docs, y Adyen mantiene su guía técnica en Adyen Docs. No necesitas casarte con una estrategia sin leer cómo funciona realmente cada flujo.

Una tabla para aterrizar la comparación

La tabla no dice que uno gane siempre. Dice que el criterio cambia cuando el volumen, la criticidad y la gobernanza pesan más que la velocidad inicial.

Resiliencia: pagos que no se caen cuando el servicio sí importa

En una plataforma pública, un pago fallido no es solo una conversión perdida. Puede ser una cita que no se confirma, una tasa que no se paga, un trámite que se detiene o una cola de soporte que crece. Por eso la resiliencia no es un lujo técnico, es parte del servicio.

Adyen tiene reputación de trabajar bien en entornos de alto volumen y con necesidades de routing y disponibilidad más sofisticadas. Stripe, por su parte, también tiene infraestructura robusta, pero GOV.UK puede haber priorizado otra mezcla de control, soporte y operación. El punto no es cuál aguanta más, sino qué arquitectura encaja mejor con el riesgo que estás dispuesto a asumir.

Si tu plataforma depende de un solo PSP para toda la capa de cobro, el riesgo no es teórico. Un incidente en un proveedor puede dejarte sin recaudo durante minutos u horas. En un negocio privado eso ya duele; en gobierno, además, afecta confianza pública. Por eso los equipos grandes suelen pensar en redundancia, en rutas alternativas y en observabilidad de extremo a extremo.

Qué mirar para medir resiliencia de pagos

Si tú lideras producto o ingeniería, revisa estos puntos antes de mover un procesador:

1. Tasa de autorización por método y por país.
2. Latencia media y percentiles de respuesta.
3. Manejo de webhooks caídos o duplicados.
4. Soporte para retries seguros y idempotencia.
5. Herramientas de monitoreo, alertas y reconciliación.
6. Procedimientos de fallback si un adquirente falla.

No necesitas tener todo perfecto desde el día uno, pero sí necesitas saber qué pasa cuando algo sale mal. La resiliencia se diseña antes del incidente, no después.

En servicios públicos, además, el volumen de usuarios no siempre es uniforme. Puede haber picos por fechas de vencimiento, campañas, impuestos o trámites masivos. Ahí el proveedor debe aguantar picos sin degradar la experiencia. Si una plataforma de gobierno se cae en día de pago, el problema escala rápido.

Soberanía de pagos: quién controla la capa crítica

La palabra soberanía se usa mucho, a veces demasiado. Aquí tiene un sentido concreto: cuánto control tienes sobre una función esencial de tu servicio. Si el pago es parte del acceso al Estado o a una plataforma central, depender de un proveedor externo para cobrar no es un detalle menor.

Esto no significa que debas construir tu propio procesador. Significa que debes entender dónde termina tu control y dónde empieza el del tercero. ¿Puedes cambiar de PSP sin rehacer toda la lógica de negocio? ¿Puedes enrutar pagos por país o por método? ¿Puedes exportar datos de forma limpia? ¿Puedes negociar condiciones sin quedar atrapado por integraciones opacas?

En Latinoamérica esta conversación es todavía más sensible. Muchas organizaciones usan proveedores globales, pero operan con realidades locales: adquirencia fragmentada, métodos alternativos, monedas volátiles, regulación cambiante y equipos pequeños. Si dependes de una sola pieza para cobrar, cualquier cambio comercial o técnico te afecta más de lo que parece.

Por qué esto importa en LatAm y Ecuador

En la región, la soberanía de pagos tiene tres capas muy prácticas:

• Regulatoria: cumplimiento local, reportes y tratamiento de datos.
• Operativa: capacidad de soportar métodos de pago que sí usa tu público.
• Económica: comisiones, FX, liquidación y acceso a adquirentes.

En Ecuador, por ejemplo, muchas plataformas no compiten solo por UX, sino por cobertura real de métodos y por la facilidad de conciliar cobros con procesos internos. Si el proveedor te obliga a operar con demasiada fricción, terminas pagando el costo en soporte y abandono.

La lección de GOV.UK es simple: cuando el pago es infraestructura, el criterio de compra cambia. Ya no buscas solo una API bonita. Buscas control, salida, trazabilidad y capacidad de negociación.

Lecciones prácticas si gestionas una plataforma grande

Si tú trabajas en una empresa, fintech, marketplace o entidad pública, este caso te deja varias acciones concretas. No hace falta copiar a GOV.UK, pero sí aprender de su decisión.

1. Mide costo total, no solo tarifa

Haz una hoja con estos datos por proveedor:

• fee por transacción
• % de aprobación
• costo de contracargos
• tiempo de liquidación
• costo de soporte interno
• horas de mantenimiento al mes

Si no tienes todos los datos, empieza por los que sí puedes medir. Lo importante es comparar con el mismo criterio y no dejar fuera el costo humano.

2. Diseña salida desde el principio

No te quedes con una integración que solo funciona en una dirección. Documenta cómo exportar transacciones, cómo migrar tokens, cómo mapear estados y cómo cambiar de proveedor sin interrumpir el servicio. Si tu arquitectura no contempla salida, tu poder de negociación baja.

3. Separa lógica de negocio de lógica de PSP

Tu aplicación no debería saber demasiado sobre un proveedor específico. Crea una capa de abstracción para métodos, estados y webhooks. Así puedes cambiar de Stripe a Adyen, o a otro PSP, con menos dolor.

4. Prueba fallos de verdad

Simula webhooks duplicados, timeouts, reintentos y caídas parciales. No basta con que el flujo feliz funcione. En pagos, el flujo feliz es solo una parte pequeña de la historia.

5. Revisa dónde está tu dependencia real

A veces crees que dependes del procesador, pero en realidad dependes del adquirente, del método de pago o del sistema de conciliación. Identifica esa cadena antes de que un incidente te obligue a hacerlo.

Qué significa para producto, ingeniería y finanzas

Para producto, este cambio recuerda que el checkout no es solo conversión. También es riesgo operativo, cobertura y costo. Si tu roadmap de pagos solo habla de más métodos y mejor UX, estás dejando fuera la parte que sostiene el negocio.

Para ingeniería, el mensaje es otro: la arquitectura de pagos debe ser reemplazable. Si no puedes cambiar de proveedor con esfuerzo razonable, tienes una dependencia demasiado fuerte. Eso no se nota en el sprint demo, pero sí cuando cambian las condiciones comerciales o aparece un incidente.

Para finanzas, el caso de GOV.UK muestra que el proveedor de pagos debe evaluarse como infraestructura crítica. No es un gasto aislado. Es una decisión que afecta margen, continuidad y capacidad de escalar sin sorpresas. En una plataforma pública, además, afecta percepción ciudadana.

Si quieres ver cómo se documentan estos flujos en serio, vale la pena leer la guía de webhooks de Stripe y la documentación de pagos de Adyen. Ahí puedes comparar cómo modelan eventos, estados y confirmaciones, que al final es donde se gana o se pierde estabilidad.

Tabla resumen

En resumen práctico: si el pago es una pieza crítica de tu servicio, no lo evalúes como si fuera un simple plugin. Míralo como infraestructura. Ahí es donde casos como el de GOV.UK dejan de ser noticia ajena y pasan a ser una guía útil para tu próxima decisión.