An order is paid successfully, but no one in the admin knows; a customer waits for a verification code, but the email never arrives. These problems are usually not because "the system did not send it," but because one part of the notification chain is not configured: the sending method, the push service, or the scheduler. This article explains the three sections under "Settings → Notifications" in the admin.

KingCMS X1 storefront example
Orders and payments are completed on the storefront; notifications are determined by admin settings.

1. Email: System Messages

The path is "Settings → Notifications → Email" (/admin/settings/notify/mail). System emails (such as email verification code login) are all sent according to the configuration here. There are two sending methods:

  • SMTP: Enter the sending server, port, encryption method, username, and password; this is the default method and is suitable for sites that already have a corporate mailbox or email service.
  • Cloudflare Email Sending: No self-hosted SMTP is required, but a Workers Paid plan is needed; first verify the sending domain in Cloudflare, then enter the account ID and API token.

Both methods share the "From Email" and "Sender Name" fields. The From Email field is required, otherwise email cannot be sent. When switching sending methods, the page only shows the fields required by the current method; hidden fields are not saved, and saved SMTP settings are not cleared. The API token and SMTP password are both stored as secrets and are not displayed again after saving; submitting the field empty keeps the original value.

There are several boundaries to know for the Cloudflare method: it only sends through Cloudflare, and failures do not automatically fall back to SMTP or retry automatically; attachments and reply-to addresses are not supported; the connection timeout is 8 seconds and the entire request timeout is 20 seconds. The From Email must use an address under a verified domain, otherwise it will be rejected.

2. Mobile Push: Payments and Refunds

The path is "Settings → Notifications → Mobile Push" (/admin/settings/notify/ntfy). It is used to push messages to a specified topic when a payment succeeds or a refund succeeds, and requires an available push service (self-hosted or public).

Three items must be filled in: the service address (for example https://ntfy.example.com, which must start with http/https), the topic name (subscribers must subscribe to the same topic), and the access token (fill in when the server requires authentication). Push events can be set to "Payment succeeded, refund succeeded," "Payment succeeded only," "Refund succeeded only," or "Do not push." Push is only sent after both the service address and topic are filled in; if either is empty, or the event is set to "Do not push," nothing will be sent.

The push content includes the order number, amount, and payment channel. No service restart is required after changing settings; they take effect the next time the task runs.

KingCMS X1 admin settings example
Notification settings are under "Settings → Notifications" and are executed by background tasks after saving.

3. Common Prerequisite: cron:run

Mobile push is executed by a background task, and you need to configure cron:run to run once per minute according to the installation documentation: system crontab, systemd timer, or BaoTa "Scheduled Tasks" all work; choose a 1-minute interval. If cron is not configured, orders and refunds themselves are not affected, but notifications will not be sent—this is the most common reason for "configured but not working."

Email is sent synchronously and does not depend on cron; however, if the sending parameters are wrong, verification code emails will fail directly. The two notification types are independent: email failure does not affect push, and an unconfigured push does not affect email.

4. Troubleshooting Order

  1. First check whether "From Email" is filled in; then check whether the fields required by the sending method are complete.
  2. For the Cloudflare method, check: whether the plan is Workers Paid, whether the sending domain is verified, and whether the token permissions include Email Sending.
  3. For mobile push, check: whether both the service address and topic are filled in, whether the event is set to "Do not push," and whether the server requires a token.
  4. Finally check cron: whether the background task runs every minute and whether there are cron:run records in the logs.

Summary

The notification chain has three parts: email handles system messages, mobile push handles payment/refund alerts, and cron keeps push running. First fill in the two "required" items—From Email and push topic—then confirm that cron is running; most "not receiving notifications" problems can be identified this way.