Rewards and profile

Rewards shows customer-benefit demonstrations in the WordPress presenter. Real points accrual, eligibility, reward redemption and history must be backed by a server before they can be represented as actual rewards.

Profile should show the signed-in customer's authorised fields and permit permitted edits. Current customer-field saves append records in MariaDB; the newest record is selected by the original server write time. Log out must clear approved secure credential storage and must not claim server revocation if the network is unavailable.

Rewards need authoritative accounting

The presenter shows loyalty and benefits interfaces, but real earned points, balances, eligibility and redemptions require a server-owned ledger. A displayed points balance cannot be trusted if it was calculated only in a browser preview. Earning, spending, refund adjustment and reversal rules must be approved for the selected venue and customer identity.

Customer interactions

A customer can browse Rewards to understand available benefits. Once an actual service exists, the view should separate available points, pending credits, expired rewards and used benefits. A redemption must not be considered complete until the server enforces the eligibility and returns confirmation. A venue change must not silently make venue-specific rewards universally redeemable.

Profile connection

Rewards should operate against the authenticated HSLG customer UUID, not a WordPress user/post identifier or an email typed into a form. The account profile can display approved personal fields retrieved with a bearer token and updated by append-only MariaDB writes. The same 'latest profile field' selection is not an appropriate implementation for a financial-style points ledger. Points need transactional integrity and explicit reversal semantics.

What is not finished

The native rewards provider currently returns no real balance. A full earning/redemption API, fraud rules, cashier verification and privacy policy remain open. The browser presenter can illustrate a redemption but must label it a demo. Do not distribute a QR image that appears redeemable until signed, scoped, expiring identifiers and server checks exist.

Test scenarios

Exercise new customers with no history, duplicate earn events, reversed purchases, wrong-venue attempts, expired offers, lost network during redemption and attempted second use of a consumed voucher. Reconcile server ledger state before showing permanent customer success. Report non-secret transaction identifiers and the venue when correcting errors.