Webhook / Polling

Definición

Webhook y polling son los dos modelos clásicos para informar a un cliente de un cambio de estado del lado del servidor (un pago liquidado, una transferencia recibida, un documento firmado).

• Webhook (push): el servidor envía una petición HTTP al cliente en cuanto se produce un evento.
• Polling (pull): el cliente consulta periódicamente al servidor para ver si hay novedades.

La elección es estructurante para cualquier integración de API fintech, con implicaciones importantes en la latencia, la fiabilidad, la complejidad y el coste.

Modelo webhook

Baja latencia, carga mínima (un mensaje por evento), pero complejidad del lado del cliente (endpoint público, firma, reintentos, idempotencia) y un endpoint que mantener disponible 24/7.

Modelo polling

Latencia media (N segundos), carga elevada (N peticiones por minuto y por recurso), pero baja complejidad del cliente (un simple GET) y ningún endpoint que exponer.

Comparación detallada

Casos de uso fintech

• Webhook (preferido): Stripe, Adyen, Mollie (notificaciones de pago), Bridge, Tink, TrueLayer (PIS), DocuSign, Yousign (firma), Sumsub, Onfido (KYC).
• Polling: apps móviles sin backend, o un evento urgente y frecuente (estado de blockchain) — poco frecuente en producción.

Buenas prácticas de webhook

• Seguridad: verificar siempre la firma (HMAC o RFC 9421), HTTPS, IP allowlisting, verificación del timestamp (anti-replay).
• Fiabilidad: reintentos exponenciales del lado del servidor, idempotency key del lado del cliente (procesar cada evento una sola vez), ACK 2xx rápido (si no, encolado asíncrono), orden no garantizado.
• Observabilidad: registrar todos los webhooks, monitorizar la tasa de error y la latencia del ACK, alertar sobre los reintentos (herramientas: Hookdeck, Svix).

Buenas prácticas de polling

Backoff exponencial (no machacar cada segundo), ETag / If-None-Match (304 si nada cambia), long polling (el servidor mantiene la conexión hasta 30 s) y paginación por cursor desde el último checkpoint.

Webhook + polling = lo mejor de ambos

Muchas fintech ofrecen los dos: el webhook como canal principal, el polling como fallback y una conciliación periódica (GET) para asegurarse de que no se ha perdido ningún evento. Stripe, Bridge y Adyen recomiendan este patrón híbrido.

Alternativas modernas

Server-Sent Events (push unidireccional), WebSockets (full-duplex, tiempo real intensivo), gRPC streaming y MQTT/AMQP/Kafka para volúmenes muy altos. Los webhooks siguen siendo dominantes en fintech por ser simples, compatibles con REST y soportados universalmente.

Lo que webhook / polling no es

• No es un protocolo: son patrones sobre HTTP, no estándares formales.
• Un webhook no es un callback: el callback es inline dentro de una petición, el webhook es una llamada autónoma.
• El polling no es retry: el polling es regular, el retry se produce en caso de fallo.
• No es una garantía de exactly-once por sí solo: hace falta webhook + idempotencia + checkpoint en base de datos.

En el ecosistema PSD2 / Open Finance

• PIS: el Berlin Group ofrece una notification_url (webhook) para señalar el fin de un pago.
• AIS: pocos webhooks (los ASPSP rara vez hacen push), de ahí un modelo más bien de polling para refrescar.
• PSD3 / FIDA: deberían estandarizar los webhooks (consentimiento, intercambio de datos).
• VoP: síncrono (request/response).
• Wero / SCT Inst: notificación push móvil, cercana al modelo webhook del lado de la app.

Ejemplos concretos

• Stripe: webhooks para ~200 tipos de eventos (payment_intent.succeeded, charge.refunded), con dashboard de configuración y simulación.
• Bridge: webhooks payment.completed, account.refreshed, consent.expiring, firmados en HMAC SHA-256.
• Sumsub: webhook applicantReviewed al final del KYC.
• Herramientas: ngrok y RequestBin para probar en local, Svix y Hookdeck en producción.
• Coste: un actor ingenuo que hace polling de 100 K clientes cada 30 s genera 3,3 M de peticiones/hora — migrar al webhook reduce el coste en ~99%.
• Exactly-once fallido: abonar a un cliente en cada webhook sin idempotencia conduce, tras un reintento, a un doble abono — deduplicar siempre por event_id.