Rewards and limits.

A reward is optional sugar on top of recognition. Every achievement works without one, and most programs mix both: recognition-only milestones for the small steps, a real reward on the moments that matter. Each achievement can carry at most one reward, and a member can earn each achievement once, so one reward rule can never pay the same member twice.

Reward types

Rewards draw from your own active products, picked in the reward editor on the setup page. Four types exist:

The linked product must be yours and active. If it is later deleted or deactivated, the reward shows "The linked product is no longer active." with a Choose another product action, and new deliveries wait until you fix it.

Start and end dates

Each reward can carry an Available from and an Until date. Leave both empty to keep the reward always available. Outside the window the achievement can still be earned; it no longer pays. A reward you attach without a start date becomes available the day you save it, so achievements earned before the reward existed are never paid after the fact.

Grant caps and the uncapped confirmation

The Grant cap is the most members who can receive the reward: "The most members who can receive this reward. Leave empty for no cap." First earned, first served. Once the cap is reached, later earners still get the achievement, without the reward.

Leaving a reward uncapped is a real commitment: every eligible member can receive it once. The page asks you to confirm this once, at the moment you introduce an uncapped reward (Continue without a cap), and does not nag you about it on every later save. Adding a cap later is always possible; it never takes back anything already delivered.

The review step shows your total exposure before you commit: the estimated audience and the most members who could receive each reward.

What members are shown before earning

Honesty is enforced by the product. The What the member sees preview in each reward editor is exactly what the wallet promises on an un-earned milestone:

• Requirement: how to earn it.
• Reward: what it pays.
• From: your business name.
• Validity: "30 days from delivery", or "Follows the product's own dates".
• Availability: "First 100 members" when capped, "Every member, once" when not.

When a reward stops being available (cap reached, window ended, or product broken), the promise disappears from un-earned milestones. Members are never shown a reward they can no longer get.

How rewards reach members

Rewards deliver on their own. You do not approve them one by one, and in the normal case there is nothing for you to do. When a member earns an achievement that carries a reward, the reward lands in their wallet right after the moment, and if their wallet is open it updates live.

A pending reward is one the member earned but that has not reached their wallet yet. Reward Loyalty saves every pending reward in the database the instant the achievement is earned, so a failed request, a slow moment, or a server restart never loses it. Until it arrives, the member sees "Reward on its way", never an error.

If the first try does not go through

When a reward cannot be added on the first attempt, Reward Loyalty keeps trying on its own for a few minutes, up to three attempts, before it marks the reward as failed. Delivery moves in small batches: each run adds up to 20 rewards, so one page load can never tie up the server, and the next run continues where it left off. A member can never receive the same reward twice, however many times a delivery is retried.

How often delivery runs

How often the checks run depends on your server, and none of it needs setup on your part:

• With cron set up, pending rewards are checked and delivered every minute. This is the recommended setup; it takes one line in your server's crontab, shown under Cron / scheduler.
• Without cron, ordinary use of the site delivers them. The next time an administrator, partner, or staff member does anything on the site, delivery runs in the background, at most once a minute.
• With no cron and no activity, the reward waits in the database until someone uses the site again, or until an administrator delivers it by hand. Nothing expires and nothing is lost while it waits.

Delivering by hand

Running delivery by hand is optional. Reach for it when you want an immediate result, when you are testing, or when you are chasing down one stuck reward. It is not routine work, because the checks above cover day-to-day running on every install. An administrator opens the Achievement reward delivery panel in the Health Center and presses Deliver pending rewards now. The button is safe to press as often as you like, and a reward can never deliver twice.

If your site runs a background worker

Most self-hosted installs run without a background worker, so rewards deliver right after the action that earns them. If your install runs a database or Redis queue with a worker, rewards deliver in the background within seconds instead. If the queue is switched off (the null driver), the reward is still saved the moment it is earned, and the checks above or a manual run deliver it later. No reward is ever lost, whichever setup you run. See Queue driver guidance.

When delivery fails

The Reward deliveries section of the achievements page tracks every reward: how many were delivered, which are on their way, and which need attention. A delivery that keeps failing stops retrying after three attempts and waits for you under Needs attention, with a plain reason:

Try again requeues that one delivery immediately. Fix the cause first, or it will land back in the same list. While a delivery sits failed, the member still owns the achievement; its reward reads a calm "Reward couldn't be added", never "Reward on its way" and never an error code, so nothing false is promised while you repair it.

The status header shows Needs attention whenever failed deliveries exist, and administrators see the same backlog install-wide in the Health Center.

What is never taken back

• An earned achievement stays earned. Caps running out, windows closing, plan changes, and pauses never remove it.
• A delivered reward is never clawed back by the program. If a reward was wrong, correct it on the underlying product the way you always do: adjust points on the card, correct the stamp, deactivate the voucher. The achievements program adds no separate undo.
• Terms are locked at earning. A reward earned under the old terms delivers under the old terms, even if you edit the rule a minute later.

Related topics

• Partner setup: The wizard where rewards are attached
• Member experience: How promises and delivered rewards appear
• Achievements troubleshooting: Operator repairs and the Health Center rows