The work behind a reward that feels simple

From the customer side, a reward is a short flow.

Open the app. Pick something. Tap redeem. Use it.

We want it to feel that simple.

Behind the tap, the system has several decisions to make. The customer needs enough points. The reward has to be active. Stock may be limited. Their tier might matter. A redemption code may need to be created. Staff may need a way to verify it. The transaction has to show up in reports.

Most of the work sits below the surface.

Eligibility has to be clear

A reward can have several rules:

• A points cost
• A start and end date
• A minimum tier
• A limit per customer
• A total stock limit
• A location restriction
• A product or category condition

These rules need to agree across the customer portal, checkout, staff tools, and API.

If the portal says a reward is available and checkout rejects it, the customer sees a broken promise. If staff can redeem something the customer can't see, support gets harder.

We keep the eligibility check in one place and return a reason when it fails. That reason can then be written for the person seeing it.

"Gold members only" is useful. "Invalid request" is not.

Points need a proper ledger

A balance looks like one number. We treat it as the result of many entries.

Points are earned, spent, expired, reversed, adjusted, and sometimes restored. Each change needs an amount, a reason, a timestamp, and a link to the event that caused it.

That history matters when something goes wrong.

If an order is refunded, the system needs to know which points came from that order. If a redemption is cancelled, it needs to know whether points should return. If staff make an adjustment, the business needs an audit trail.

Updating a balance directly would be easier at first. It would leave very little to explain later.

Stock changes the redemption flow

Digital rewards can often be issued immediately. Physical rewards have inventory.

The system needs to decide when stock is reserved. It also needs to release that reservation if the redemption expires or is cancelled.

Two customers can try to claim the last item at nearly the same time. That's a small concurrency problem with a very visible result.

We handle the reservation as part of the redemption transaction. The customer should either receive a confirmed reward or keep their points. A half-finished state is hard for everyone.

Codes need a lifecycle

Some rewards are used through a code.

The code may be shown to staff, copied into checkout, or scanned from a membership card. It should be unique, hard to guess, and limited to the intended use.

A code also needs a status. Issued, used, expired, cancelled. Staff need to see enough information to verify it without gaining access to unrelated customer data.

Once used, it should stay used. Repeated taps, slow networks, and retries can't create a second redemption.

This is where idempotency becomes practical. The same request can arrive twice and still produce one result.

Checkout has to settle the order

Rewards can affect checkout in different ways.

A fixed discount reduces the total. A percentage reward needs limits. A free item needs a matching product. Free shipping depends on the delivery method. A gift card behaves more like stored value.

Then coupons enter the same order.

The business needs clear rules for stacking. The customer needs to see which benefit applied and why. Totals should stay stable between the cart, payment step, receipt, and any later refund.

We store the applied benefit on the order itself. Recalculating an old order from current rules can produce a different answer.

Staff tools are part of the customer experience

Many redemptions finish at a counter.

Staff need a quick screen to find the customer, scan a code, confirm the reward, and move on. Slow or unclear staff tools turn a smooth app flow into an awkward conversation.

Permissions matter here. A cashier may need to redeem a reward without seeing full customer history. A manager may need to reverse a mistake. The audit log should show who did each action.

The customer rarely sees these controls. They feel the result when the line keeps moving.

Messages should match the state

Customers may receive a confirmation, expiry reminder, cancellation notice, or balance update.

Those messages have to follow the real redemption state. Sending a reminder for a reward that was already used creates doubt. Announcing points before the transaction finishes can do the same.

We trigger messages from completed state changes and keep a record of what was sent.

Reporting closes the loop

Businesses need to know how rewards are being used.

That includes redemptions, points spent, reward cost, unused claims, location, tier, and the orders connected to each reward. The definitions need to stay consistent with the operational system.

This is useful for ordinary decisions. A reward may be popular and expensive. Another may be claimed often and rarely used. A tier-only benefit may have almost no eligible customers.

The goal is to make those patterns visible without turning the reward flow into a reporting exercise for the customer.

Simple takes coordination

The best version of this feature is quiet.

The customer sees an available reward, claims it, and uses it. Staff verify it quickly. The points history makes sense. Reports update later.

Getting there means working through the unglamorous cases: retries, refunds, expiry, low stock, duplicate requests, permissions, and unclear rules.

That's where a lot of the product gets built.