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.

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ó.

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.

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.

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.

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.