The transaction and the ongoing check are different things
An entitlement is what a principal is currently allowed to use or access, evaluated at the moment of use — distinct from whatever purchase or transaction originally established it. The transaction is a single, historical event; the entitlement it produces is a status that has to be actively checked every time the corresponding access is exercised, and one that can change independently of that original transaction through renewal, expiry, or explicit revocation.
Treating the historical fact of a purchase as if it were itself a permanent, self-enforcing grant conflates these two different things — a system that checks 'did this principal ever purchase this' instead of 'is this principal currently entitled to this' will keep honoring access long after a subscription lapses, a refund is issued, or an entitlement is otherwise revoked.
Designing entitlement checks to actually track current state
A robust entitlement system checks current status at the point of use rather than relying on a cached record of past purchase, and propagates changes — a cancellation, a refund, an expiry — into that current status promptly rather than leaving it to a background process that might lag well behind the actual change. The gap between when an entitlement should end and when the system actually stops honoring it is exactly the kind of window that matters in exactly the way a stale authorization cache does elsewhere.