Mini Program order reminders: why do users still not receive them after tapping Allow?

Conclusion first: after users place an order in a Mini Program, if they do not receive a reminder, it is usually not because the Mini Program is “broken,” but because three things in subscription messages are not aligned—authorization type (one-time or long-term), send timing, and template category and parameters. A user tapping “Allow” once does not mean it stays valid long-term; after a one-time authorization is used once, the next send often fails silently, and nothing appears on the page. In the common 2026 approach, first check backend send records and user authorization status, then verify whether the template is compliant; this rules out most “notification cannot be sent” issues.

1. “Reminders” in a Mini Program actually travel through several paths

What many requesters call “push” technically maps to at least four different paths: subscription messages, Official Account service notifications, SMS, and in-app prompts plus customer service messages. Their trigger conditions, user consent methods, and delivery rates vary greatly; mixing them up easily leads to “I thought it was sent, but the user says they did not receive it.” During delivery, I first confirm three things: which path this reminder uses, who triggers it, and at which step the user is asked for authorization. If these three points are not written clearly, all later troubleshooting is guesswork.

• Subscription messages: The platform allows sending only after the user actively taps “Allow”; one-time authorization generally corresponds to one send opportunity, while long-term subscription is open only in a few categories, and whether you can apply depends on platform rules.
• Official Account service notifications: These depend on whether the user follows the Official Account and are not the same as Mini Program login state; the reachable audience is usually smaller.
• SMS: Does not depend on the Mini Program ecosystem and delivery is relatively stable, but it requires signature and template filing and is billed per message.
• In-app prompts and customer service messages: Badges, order page status, and customer service replies only solve problems after “the user has already entered”; they are suitable as a fallback.

2. The user tapped “Allow,” so why are they still not receiving it later?

When a reminder does not arrive, check in the reverse direction from the backend to the user’s phone using the “four-step check,” rather than changing code right away. If the order is reversed, you may repeatedly change things that are fine, wasting schedule and budget.

1. Step 1: check the send result: In the backend or logs, was this message “successfully sent,” “rejected,” or never triggered at all. If it was not triggered, the business code probably did not call it; if rejected, it points to authorization or parameters.
2. Step 2: check the user’s authorization status: Did the user tap “Allow,” “Reject,” or check “always keep the above choice.” If a one-time authorization has been consumed, the next send fails; this kind of silent failure recurs in projects.
3. Step 3: check the template and parameters: Whether the template has been taken down or its category changed, whether parameter fields are too long, whether disallowed wording is included, and whether parameter types mismatch—all can cause direct failure.
4. Step 4: check user-side settings: Whether phone system notification permission is off, Do Not Disturb is on, or the user has manually turned off Mini Program message reception. This layer is not managed by development, but it should be written into the delivery notes.

What counts as passing: You can run one test message completely through the four steps and keep backend screenshots or records; parameter mapping, authorization settings, and exception fallbacks all have written explanations. A developer saying orally “it works on my side” alone does not pass acceptance.

3. Choosing reminder methods: a checkable comparison

There is no standard answer for choosing a reminder method; what matters is the balance between delivery necessity, cost, and interruption. The comparison below is organized according to common project delivery practice. The numbers are experience ranges, and specifics still depend on official platform documentation and category rules.

• Subscription messages: Low development cost, with a typical range of a few working days to integrate; delivery rate depends on whether the user authorizes, and it is mostly one-time; suitable for strong-action scenarios such as order status and redemption.
• SMS: Relatively stable delivery, billed per message, with a typical range of a few cents to just over one-tenth of a yuan per message; commonly used for notifications that must arrive, such as verification codes and payment results, while marketing SMS requires separate filing.
• Official Account service notifications: Require the user to follow the Official Account, so reach is limited; suitable when there is already an Official Account operation system and a need for rich-text guidance.
• In-app prompts plus customer service messages: Almost zero cost and low interruption, but effective only when the user actively enters the Mini Program; suitable as a fallback, not as the main channel.

A common practice in custom mobile delivery is “subscription messages as the front line + SMS as fallback + in-app status self-check.” But whether to add SMS fallback depends on the business value of a single notification: whether one order confirmation is worth the SMS fee can be decided with one calculation. This step is usually written into the requirement confirmation document to avoid adding a channel after launch and going through filing again at the last minute.

4. Applicable and non-applicable boundaries

Situations suitable for a complete reminder system: time-sensitive flows such as orders, payments, bookings, and redemption, where users need to come back at a specific time; customer service is overwhelmed by “status inquiries”; the business has passed category review and can apply for the corresponding subscription templates.

Situations where a reminder system is unnecessary: purely display-oriented or internal-tool Mini Programs that users already visit proactively; very small user volume and slow operations, where manual customer service replies are faster and cheaper; and scenarios where there is temporarily no capacity to continuously maintain templates and copy—if no one follows up after a template is taken down or a category changes, reminders silently fail, which is worse than not doing it. This boundary should be written clearly at project initiation, not patched in after launch.

5. Delivery reality: scheduling when budget is tight and timeline is short

A common constraint: the budget is limited and only two or three weeks are left before launch, yet the requester wants all notifications done at once. A common approach is to connect only one path first, “order status,” place the authorization request at the moment the user successfully places an order, and leave other notifications for phase two. The trade-off is that every later notification requires going through authorization guidance and template verification again, significantly increasing revision rounds, so the template names to be integrated later should be listed in the requirements document in phase one. In terms of experience range, reserving one to two days specifically for notification integration testing is more stable; leaving only half a day often means discovering on launch day that the authorization has already been used up.

Frequently asked questions

The user tapped “Allow” once, so why can they not receive it later?

One-time subscription authorization generally corresponds to only one send opportunity and becomes invalid once used. If multiple reminders are needed, request authorization again each time the user triggers a business action, or switch to a long-term subscription category; whether it is available depends on platform rules.

The backend shows the message was sent successfully, but the user still says they did not see it. Whose problem is it?

A successful send only means the platform has accepted it, not that it has been displayed. Common reasons are that the user’s phone notification permission is off, Do Not Disturb is on, or the message is folded into service notifications; during acceptance, including user-side settings in the checklist is more reliable.

Can subscription message templates be written freely?

No. Templates must be selected from the category templates provided by the platform; field names and value formats are constrained, and the copy cannot contain marketing inducements. A common practice is to first get the platform template working, then adjust wording within the allowed range.

The reminder feature is written into the contract; how do you judge whether it is done properly?

Look at three things: a test message can run through completely, parameters and templates are documented, and exception cases (authorization rejected, parameters too long) have fallback plans. If the clause only says “supports message push,” it is basically impossible to verify during acceptance.

If SMS is used as a fallback, will costs get out of control?

SMS is billed per message, with an experience range of a few cents to just over one-tenth of a yuan each; at high volume, frequency control and deduplication are worth doing. A common practice is to send SMS only for high-value nodes and leave the rest to subscription messages and in-app prompts.

If you are working on a Mini Program, do not rush to add push features first: write “which notification needs to be delivered, when the user authorizes, and how to fall back if it fails” into the requirements document, then decide which channels to use. For parts involving categories, templates, and authorization rules, check item by item against official platform documentation and the delivery acceptance checklist. For projects with small user volume and slow pace, making customer service replies smooth is often more cost-effective than building a reminder system.