Un correo de fallo en el pago resulta verdaderamente útil cuando explica con claridad qué requiere atención y ofrece una forma segura de resolverlo. Diseña la notificación en Migma a partir de datos de facturación verificados y asegúrate de que los responsables de facturación y de envío confirmen que esa información sigue siendo válida en el momento exacto del disparo.
Migma publica esta guía para equipos de SaaS y modelos de suscripción que revisan sus notificaciones de cobro. El objetivo se centra en la calidad de los mensajes y en la validación de estados, no en la implementación técnica de la pasarela de pagos. Las fuentes oficiales se consultaron el 15 de octubre de 2026. Los textos de ejemplo corresponden a propuestas de planificación y deben adaptarse a la política de facturación de cada empresa.
Identifica con claridad qué estado describe el mensaje
Un intento fallido es un evento del pasado. La factura puede continuar pendiente, el cliente puede haber actualizado ya su método de pago o un intento posterior puede haberse completado con éxito. Cada una de estas situaciones exige un mensaje distinto.
Antes de redactar, pide al responsable de facturación que defina qué estado actual justifica el envío del correo. Conviene diferenciar entre «ha fallado un pago» y «el cliente aún tiene que realizar una acción». No des a entender que el servicio se interrumpirá hoy salvo que esa consecuencia y su fecha límite estén plenamente confirmadas.
La documentación de webhooks de Stripe recuerda que no se garantiza el orden de entrega de los eventos y que estos pueden recibirse más de una vez. Aunque se trate de un aspecto de implementación técnica para el equipo de desarrollo, influye de forma directa en la redacción: un evento de fallo antiguo no debe convertirse, por sí solo, en la afirmación de que el usuario no ha pagado.
Proporciona a Migma un brief de facturación validado
Revisa el contexto de marca e introduce el objetivo del correo, la terminología aprobada, los campos obligatorios y el destino del enlace de acción. Emplea valores ficticios de muestra en el brief de diseño. Para evaluar la legibilidad y la estructura no hace falta exponer números de tarjeta reales, credenciales ni registros privados de clientes.
Indica a Migma que genere un mensaje directo y sosegado. Sitúa la incidencia y el paso a seguir por delante de cualquier elemento decorativo. Mantén visible la vía de contacto con soporte, recurre a un remitente reconocible y asegúrate de que el texto del botón describa con precisión el destino. «Revisar datos de pago» aporta mucha más claridad que un genérico «Continuar».
Evita disculpas automáticas, no culpes al banco del usuario ni aventures diagnósticos técnicos sobre el fallo salvo que el sistema de cobro proporcione un motivo oficial confirmado. El correo puede limitarse a indicar con transparencia que no se ha podido completar la transacción, sin necesidad de inventar la causa.
Adapta el texto a la acción requerida
Los siguientes ejemplos muestran cómo cambia el redactado en función de lo que deba hacer la persona que lee el mensaje. Sustituye los campos entre corchetes antes del envío; son variables de planificación y no sintaxis definitiva de producción.
El cliente debe actualizar sus datos de pago
«No hemos podido procesar el pago de [plan]. Revisa los datos de pago en tu cuenta. Si los has actualizado recientemente, accede a tu página de facturación para comprobar el estado actual.»
Utiliza esta variante únicamente cuando el responsable de facturación confirme que el usuario tiene una acción pendiente a su disposición. Incluye el importe y la divisa si resultan precisos y clarificadores. Evita mostrar cifras sin el formato de divisa correspondiente.
El sistema reintentará el cobro y no se requiere ninguna acción de momento
«El último intento de cobro para [plan] no se ha completado con éxito. Volveremos a intentarlo según el calendario indicado en tu página de facturación. Puedes revisar tus datos o escribirnos si necesitas ayuda.»
Cualquier referencia a un reintento debe ajustarse al proceso configurado en el sistema. No copies plazos genéricos en todas las notificaciones. Si la fecha del próximo reintento se desconoce o puede variar, remite al panel de estado de la cuenta en lugar de presentar una estimación como un compromiso en firme.
El pago ya se ha completado
No envíes una notificación de fallo antigua simplemente porque se quedó encolada previamente. El responsable del flujo debe determinar el resultado tras un cobro correcto y preparar la confirmación oportuna. Se trata de una decisión de enrutamiento del sistema, no de un problema que el redactor o diseñador pueda solucionar modificando un correo ya desfasado.
Define un único responsable para el envío de notificaciones
La guía de Loops sobre correos de pago distingue entre las notificaciones automáticas de Stripe, los flujos basados en eventos de Loops y los correos transaccionales lanzados desde el servidor. Asimismo, su documentación diferencia la gestión de bajas de los flujos de marketing frente a los envíos transaccionales críticos.
Confirma qué vía emplea tu equipo y qué competencias asume cada herramienta. Un flujo con identidad de marca y una alerta estándar de Stripe no deberían transmitir información contradictoria sobre una misma factura. Gestiona los permisos de marketing y las comunicaciones esenciales de cuenta con los responsables de plataforma y cumplimiento correspondientes; esta guía no propone eludir los enlaces de baja introduciendo mensajes promocionales en avisos transaccionales.
Migma permite exportar el diseño revisado mediante la descarga del HTML. Quien implemente la plantilla la adaptará a la sintaxis y a los campos que admita la plataforma final. Este proceso no asume una sincronización nativa directa entre Migma y Loops o Migma y la facturación de Stripe.
Comprueba el correo en la bandeja de entrada, no solo en la vista previa
Pasa el borrador de Migma por Email Preflight. Verifica los enlaces clave, el redactado, la maqueta y la visualización tanto en modo claro como en modo oscuro. Que el diseño supere las pruebas no certifica por sí solo el estado real de la factura, la recepción por parte del proveedor ni la entregabilidad en la bandeja principal.
Pide al responsable de envíos que pruebe el correo final en el entorno de destino utilizando casos de prueba controlados: nombres de plan extensos, ausencia de campos opcionales, distintos formatos de moneda o situaciones en las que el usuario paga mientras espera. Haz clic en el botón del correo recibido y verifica que redirige exactamente a la página de facturación correcta.
Prueba también qué ocurre si un evento se repite o si un aviso de fallo desfasado llega tras confirmarse el pago. Documenta el comportamiento previsto frente al resultado real. El equipo de desarrollo debe conciliar los eventos duplicados o desordenados a nivel de sistema, sin pedir al equipo de contenido que lo enmascare con textos excesivamente ambiguos.
Mantén el mensaje alineado con la política de la empresa
Archiva en un mismo lugar el texto validado, el responsable de la política de facturación, la versión de la plantilla en producción y los resultados de las pruebas. Revisa la notificación siempre que cambien los plazos de reintento, las condiciones de acceso al servicio o la página a la que se dirige al cliente para actualizar sus datos.
Diseña el mensaje en Migma una vez definidos los datos y el siguiente paso del usuario. Una notificación de cobro eficaz genera confianza gracias a un estado preciso, un diseño claro y una acción que el cliente puede resolver sin fricción.
Preguntas frecuentes
¿Un evento de pago fallido demuestra que la factura sigue impagada?
No. Es posible que un intento posterior se haya completado con éxito. El responsable de facturación debe comprobar el estado actual y determinar si una notificación en cola debe enviarse o descartarse.
¿Puede Migma decidir el calendario de reintentos?
Esta guía utiliza Migma para diseñar y revisar los contenidos. El sistema de facturación y su responsable determinan los plazos de reintento, el acceso al servicio y el estado de las facturas.
¿Por qué conviene definir un único responsable para los envíos?
Tanto las alertas nativas de Stripe como otro flujo automatizado pueden estar operativos a la vez. Conviene centralizar la responsabilidad para evitar que el cliente reciba instrucciones contradictorias sobre la misma factura.
¿Qué comprobación es clave una vez completado el pago?
Comprobar qué sucede cuando un cliente paga durante el periodo de espera o si se procesa un aviso de fallo antiguo tras completarse el cobro. El flujo debe guiarse por la regla de estado actual validada, en lugar de emitir un mensaje de fallo desfasado.