Reconcile return rewards without paying twice

A return machine and a reward programme answer different questions. The machine establishes whether a container passed its physical acceptance process. The programme decides whether that event qualifies for a benefit, for which participant and under which budget. Joining those decisions carelessly can create duplicate credits or a customer message that the ledger cannot support.

Define the authoritative event

Use a unique, persistent acceptance-event ID. Include the equipment and site, event time, qualified format and the rule version used at the point of return. Rejection and uncertain classification are separate outcomes; neither should be treated as an accepted item merely because the screen showed recognition feedback.

Put eligibility on the programme side

Document participant identity, eligible site and package, campaign window, per-person limits and available budget. Those decisions belong to an authorized server-side system. The visitor can receive an immediate acknowledgement of the physical return, followed by a confirmed reward status when the programme responds. If the service is offline, describe the pending state accurately.

Make correction possible

Reconcile these records by stable IDs and time windows. Test duplicate delivery, delayed responses, reversal and customer-support review. Keep an audit trail of corrections rather than deleting the original event. A browser-side button, QR display or mock dashboard must never be the authority for a real payment or credit.

Work through a disputed return

A visitor says the machine accepted a container but their account has no credit. Support should be able to find the equipment event by a safe reference, see whether the programme received it, check the eligibility decision and identify any pending or rejected ledger action. If the event never reached the programme, the integration owner investigates delivery. If the programme rejected it, the programme owner explains the rule. The site attendant should not be expected to alter a financial record they do not own.

Reconcile by exception, not by silent adjustment

At an agreed interval, compare unique accepted-event IDs with programme decisions and benefits issued. Put missing, duplicate and reversed records in an exception queue with a reason and owner. Preserve the original record when a correction is made. This protects both the participant and the sponsor: a later audit can see what happened rather than only the final balance.

If you already have a loyalty platform, discuss the event boundary before designing a new participant app. The integration checklist helps your teams agree the acceptance and ledger owners.