Al crear un mandato en Forpay, el header processId determina el modo de integración bajo el cual opera ese compromiso de pago. Este valor es asignado en la creación de cada mandato y define quién es responsable de las comunicaciones hacia el cliente final.
El header processId en la creación de mandatos
processId en la creación de mandatosPOST /white/label/mandate
Authorization: Bearer <token>
processId: HYBRID ← define el modo de operación
...Los dos valores posibles son HYBRID y WHITE_LABEL.
Modos de operación
processId: HYBRID
processId: HYBRIDForpay co-gestiona la comunicación con el cliente. Además de notificar a la Empresa vía webhooks, envía correos directamente al cliente final en eventos clave (activación, cobros, recordatorios).
Recomendado para: integraciones que prefieren delegar las comunicaciones al cliente a Forpay.
processId: WHITE_LABEL
processId: WHITE_LABELForpay opera en modo silencioso frente al cliente final: no envía ninguna comunicación directa al usuario. Toda la experiencia de notificación queda a cargo de la Empresa, construida a partir de los eventos recibidos por webhook.
Recomendado para: empresas con canales de comunicación propios o que quieren una experiencia 100% bajo su marca.
Tabla de responsabilidades
| Comunicación al cliente | HYBRID | WHITE_LABEL |
|---|---|---|
| Magic Link | Forpay | Tu sistema |
| Aviso de cobro exitoso | Forpay | Tu sistema |
| Aviso de cobro rechazado | Forpay | Tu sistema |
| Otros avisos | Forpay | Tu sistema |
| Webhooks a la Empresa | Forpay | Forpay |
En ambos modos Forpay siempre notifica a la Empresa vía
activationWebhookypaymentWebhook. La diferencia es únicamente en la comunicación hacia el cliente final.
Webhooks a implementar (especialmente en WHITE_LABEL)
| Webhook | Evento |
|---|---|
activationWebhook | Activación o anulación de un mandato |
paymentWebhook | Resultado de cada intento de cobro (exitoso, rechazado, en proceso) |
Ver Introducción a Webhooks para el detalle de payloads y validación HMAC.

