Clase 14 · 2:56
Cómo enviar mensajes transaccionales
Enviar una confirmación útil desde una operación verificada y comprobar qué pasó con la entrega.
Cargando el tutorial…
Lo que vas a aprender
- Preparar una plantilla desde una operación confirmada.
- Retener una solicitud para revisar sus datos y destino.
- Comprobar duplicados, fallos y acceso al comprobante.
Por qué importa
Una confirmación clara permite saber qué pasó con una operación y encontrar su comprobante.
Casos y datos ficticios. Las ilustraciones explican el proceso; no certifican envíos reales.
Aplicá esta clase
Checklist de mensajes transaccionales
Casos, esquema de trabajo, pruebas y una ficha para aplicar.
Bajate la guíaPDF de 4 páginas · Nombre, empresa y email laboral
Transcripción
Descargar textoConfirmá algo que pasó.
Soy Diego, de Kunko. Ana termina una transferencia y necesita saber qué pasó con su plata. El comprobante le confirma el estado y le permite volver a consultar la operación. Una promoción en ese momento puede distraerla. Hoy vamos a preparar un mensaje transaccional: desde la operación confirmada hasta la plantilla, la llamada desde el backend y el seguimiento de la entrega. El caso y los datos de esta clase son ficticios.
La operación manda.
El punto de partida es tu sistema de operaciones. Confirmá el estado antes de escribir transferencia completada. En este diseño, el backend conserva el identificador de la operación y registra si ya pidió ese comprobante. Si recibe dos veces la misma señal, revisa ese registro antes de repetir el envío. Es una decisión de nuestra integración: no estamos suponiendo que la API de mensajes elimina cualquier duplicado. Un clic en la pantalla tampoco demuestra por sí solo que la operación terminó.
Prepará la plantilla y sus ajustes.
En Transactional creamos una plantilla de email y elegimos un remitente verificado. El asunto dice tu comprobante está disponible. En el cuerpo mostramos la referencia de la operación y una acción para consultarla. Completamos las variables con datos del disparador. Durante la revisión dejamos los mensajes en borrador. Antes de pasar a envío automático, revisamos destinatario, retención del contenido y seguimiento. Cada ajuste tiene que corresponder al uso del mensaje.
El backend llama a la API.
En el ejemplo, el backend referencia la plantilla por su nombre de disparador, comprobante de transferencia. Incluye un destinatario ficticio y los datos de esa operación. La opción queue draft está en true: el mensaje queda retenido para revisión. La clave de la App API permanece en el servidor; no va dentro del JavaScript del sitio. El enlace del comprobante lleva a una pantalla protegida. Conocer la dirección del enlace no debería dar acceso a la información de otra persona.
Aceptado no significa entregado.
Una respuesta exitosa de la API confirma que recibió la solicitud. Después seguimos su estado: borrador, envío, entrega o fallo. En nuestro sistema registramos la referencia de la operación y el resultado del proveedor. Si hay un error temporal, definimos reintentos con límite y evitamos repetir un mensaje que ya se procesó. También probamos una dirección incorrecta y una variable ausente. Para SMS, WhatsApp o push, primero hay que conectar el proveedor o SDK del canal y comprobar sus requisitos.
Probá el recorrido completo.
La configuración de transaccionales puede permitir mensajes a personas dadas de baja. Revisá esa decisión según el propósito del mensaje y las reglas aplicables. No la uses para colar promociones en un comprobante. El checklist de esta clase reúne seis pruebas: operación pendiente, confirmada, duplicada, variable ausente, destino incorrecto y entrega fallida. Probá también que Ana solo vea su comprobante. El mensaje funciona cuando informa lo ocurrido y deja a la persona consultar o resolver el siguiente paso.