El pedido se paga correctamente, pero nadie en el panel de administración se entera; el cliente espera el código de verificación y el correo no llega. Por lo general, este tipo de problemas no se debe a que “el sistema no lo envíe”, sino a que algún tramo de la cadena de notificaciones no está bien configurado: el método de envío, el servicio de notificaciones push o el programador de tareas. Este artículo lo explica según los tres bloques de «Configuración → Notificaciones» del panel de administración.

KingCMS X1 商城前台示例
Los pedidos y los pagos se completan en el frontend; las notificaciones dependen de la configuración del panel de administración.

1. Correo: envío de mensajes del sistema

La ruta es «Configuración → Notificaciones → Correo» (/admin/settings/notify/mail). Los correos del sistema (por ejemplo, el inicio de sesión con código de verificación por correo electrónico) se envían según la configuración indicada aquí. Hay dos métodos de envío:

  • SMTP: rellene el servidor de envío, el puerto, el método de cifrado, el nombre de usuario y la contraseña; es el método predeterminado y resulta adecuado para sitios que ya disponen de correo corporativo o de un servicio de correo.
  • Cloudflare Email Sending: no requiere montar un SMTP propio, pero sí un plan Workers Paid; primero hay que verificar el dominio de envío en Cloudflare y después rellenar el ID de cuenta y el token de API.

Ambos métodos comparten el «correo del remitente» y el «nombre del remitente»; el correo del remitente es obligatorio, de lo contrario no se podrá enviar. Al cambiar el método de envío, la página solo muestra los campos que necesita el método actual; los campos ocultos no se guardan y la configuración de SMTP ya guardada tampoco se borra. El token de API y la contraseña de SMTP se guardan como secretos, no se vuelven a mostrar después de guardar y, si se envían vacíos, se conserva el valor original.

Con el método Cloudflare hay varios límites que conviene conocer: solo se envía a través de Cloudflare; si falla, no se cambia automáticamente a SMTP ni se reintenta automáticamente; no admite adjuntos ni dirección de respuesta; el tiempo de espera de conexión es de 8 segundos y el de toda la solicitud, de 20 segundos. El correo del remitente debe ser una dirección de un dominio verificado; de lo contrario, se rechazará.

2. Notificaciones push al móvil: pagos y reembolsos

La ruta es «Configuración → Notificaciones → Notificaciones push al móvil» (/admin/settings/notify/ntfy). Se utiliza para enviar mensajes push a un tema concreto cuando se produce un pago correcto o un reembolso correcto, y requiere un servicio de notificaciones push disponible (propio o público).

Hay que rellenar tres campos: la dirección del servicio (p. ej., https://ntfy.example.com, debe empezar por http/https), el nombre del tema (quien se suscriba debe suscribirse al mismo tema) y el token de acceso (rellenar cuando el servidor exija autenticación). Como evento de push se puede elegir «pago correcto y reembolso correcto», «solo pago correcto», «solo reembolso correcto» o «no enviar push». Solo se enviará push cuando estén rellenados la dirección del servicio y el tema; si cualquiera de los dos está vacío o el evento es «no enviar push», no se enviará nada.

El contenido del push incluye el número de pedido, el importe y el canal de pago. Después de modificar la configuración no hace falta reiniciar el servicio; surtirá efecto en la siguiente ejecución de la tarea.

KingCMS X1 后台设置示例
La configuración de notificaciones está en «Configuración → Notificaciones» y, una vez guardada, la ejecutan las tareas en segundo plano.

3. Requisito común: cron:run

Las notificaciones push al móvil las ejecutan tareas en segundo plano, por lo que es necesario configurar cron:run para que se ejecute cada minuto según la documentación de instalación: sirve el crontab del sistema, un timer de systemd o las «Tareas programadas» de 宝塔, con un intervalo de 1 minuto. Si no se configura cron, los pedidos y reembolsos no se ven afectados, pero las notificaciones no se enviarán; esta es la causa más habitual de que «esté configurado pero no funcione».

El correo se envía de forma síncrona y no depende de cron; pero si los parámetros de envío son incorrectos, el correo con el código de verificación fallará directamente. Los dos tipos de notificación son independientes entre sí: un fallo en el correo no afecta a las notificaciones push, y no configurar las notificaciones push tampoco afecta al correo.

4. Orden de diagnóstico

  1. Primero compruebe si está rellenado el «correo del remitente»; después, si están completos los campos que requiere el método de envío.
  2. En el método Cloudflare, compruebe: si el plan es Workers Paid, si el dominio de envío está verificado y si los permisos del token incluyen Email Sending.
  3. En las notificaciones push al móvil, compruebe: si están rellenados tanto la dirección del servicio como el tema, si el evento seleccionado es «no enviar push» y si el servidor exige token.
  4. Por último, revise cron: si las tareas en segundo plano se ejecutan cada minuto y si el registro contiene entradas de cron:run.

Resumen

La cadena de notificaciones se divide en tres tramos: el correo se encarga del envío de mensajes del sistema, las notificaciones push al móvil de los avisos de pago/reembolso y cron de poner en marcha las notificaciones push. Primero complete los dos «campos obligatorios», el correo del remitente y el tema de las notificaciones push, y después confirme que cron se está ejecutando; así podrá localizar la mayoría de los problemas de «no recibo notificaciones».