Loyalty glossary · 8. Technology and architecture (25)
Idempotency
Idempotency is the property that a repeated operation produces the same result as a single execution, so retries do not duplicate effects. In loyalty programmes, it prevents double accrual or double redemption from the same transaction.
Idempotency is not an implementation detail, it is a design requirement. A loyalty programme that processes a retried accrual request without an idempotency key has no way to know that the member already received those points. The system will happily credit them again, and the liability grows without any corresponding member activity.
The standard defence is an idempotency key. The client generates a unique key for each logical transaction, and the server stores that key with the result of the first attempt. When a retry arrives with the same key, the server returns the stored result and skips the side effect. This pattern costs almost nothing to implement and prevents the most common form of double counting.
A member who should earn 500 points from a single partner stay ends up with 1000 points when the accrual call is retried and the system is not idempotent. Across a programme issuing 10 million points per month, a 3 percent retry rate that always doubles the accrual adds 300,000 points of spurious liability every month. Those points are not earned by any real member behaviour.
The distortion reaches the metrics operators actually watch. Active-member rate depends on a clean record of qualifying activity, because one member with one stay should count once. A duplicate accrual from a retried request can make that member look like two actives in the same period, and then a reported active-member rate is inflated without any real change in behaviour.
Activity-based qualification is equally vulnerable. When a programme counts specific partner stays or tiers to move a member up, a non-idempotent system can award two stays for one hotel visit and push the member into a higher tier without any additional spend. Loyalty Register takes the position that every write operation in a programme must carry an idempotency key, and any partner integration that omits one should be rejected.