Esta página aplica a los webhooks de débito bancario, de tarjeta, de creación y pago de órdenes, y al de medio de pago registrado. La notificación de pago la envía otra plataforma y sus mecanismos están en esa misma página.
Los mecanismos
El header
notificationType llega siempre, con el mismo valor que el type del cuerpo. Sirve para enrutar, no para autenticar.
Headers fijos
TapiPay agrega a cada petición los headers que acuerdes, con un valor fijo. El caso más común es una API key enx-api-key.
- Qué entregas: el nombre de cada header y su valor, por el canal seguro que te indique el equipo de TapiPay.
- Qué validas: que el header venga y que su valor coincida con el que entregaste. Compara en tiempo constante para no filtrar el valor por diferencias de tiempo.
- Rotación: para cambiar el valor, coordina con el equipo de TapiPay la fecha y hora del cambio. Durante la ventana del cambio, acepta el valor anterior y el nuevo.
Bearer token
TapiPay envía un token en el headerAuthorization: Bearer <token>. Hay dos variantes:
En la variante OAuth 2.0, tu endpoint valida el token como cualquier otro que emita tu servidor de autorización: firma, vencimiento y audiencia.
Hash cifrado
TapiPay incluye en el cuerpo un campohash, cifrado con la llave pública RSA que entregas. Solo tú puedes descifrarlo, con tu llave privada.
En
v2, operationId es el identificador de esa notificación: el campo id en los webhooks de órdenes y de medio de pago registrado, y el campo operationId en los de débito bancario y tarjeta. Comprueba que coincidan: así un hash copiado de otra notificación no te sirve para validar esta.
Si no entregaste una llave pública, el campo hash llega igual, con valor null. La versión (v2 o por defecto) se define al configurar tu integración: pide v2.
Para generar el par de llaves:
Allowlist de IPs
TapiPay te puede proporcionar la lista o los rangos de IPs desde los que salen las peticiones de los webhooks, para que tu endpoint acepte solo esas IPs. Pídela al equipo de TapiPay para cada ambiente (homologación y producción).Pide que te avisen antes de cualquier cambio en esa lista. Una IP nueva que tu allowlist no conoce hace que rechaces webhooks legítimos.
Ejemplo: validar una petición
El orden correcto en tu handler es: validar el origen, responder 2xx rápido y recién después procesar. Este ejemplo combina un header fijo con el hash cifrado en su versiónv2.
En la versión por defecto del hash, el contenido descifrado es solo tu usuario de integración: compáralo directamente con
CLIENT_USERNAME, sin JSON.parse.Reintentos ante un rechazo
Si tu endpoint no responde 2xx, TapiPay reintenta el envío un número limitado de veces en los minutos siguientes y después deja de reintentar. Un rechazo por credenciales (401 o 403) también se reintenta, pero vuelve a fallar mientras la configuración no se corrija.
Cómo pedir la configuración
1
Elige los mecanismos
Decide qué mecanismos quieres combinar y para qué ambientes: homologación, producción o los dos.
2
Contacta al equipo de TapiPay
Pide la configuración e indica los mecanismos y los webhooks que recibes. Los webhooks de órdenes y medios de pago comparten una misma configuración; pide que la seguridad cubra todos los grupos de webhooks que recibes, para que ninguno llegue sin ella.
3
Entrega los datos por un canal seguro
Entrega los valores (headers, tokens, credenciales, llave pública) por el canal que te indique el equipo de TapiPay. Nunca envíes un secreto por correo o chat en texto plano. La llave pública no es un secreto.
4
Prueba en homologación
Valida que tu endpoint acepta los webhooks de homologación con los mecanismos activos antes de pedir la misma configuración en producción.

