Implementing a Loyalty Program in Mobile Apps
A loyalty program in a mobile app is not just "accumulate points". Behind a simple interface lies non-trivial server logic: transactional crediting, preventing fraud, point expiry, and state synchronization across sessions. The server-side cannot be underestimated here.
Data model and transactionality
Point balance cannot be stored as a single number in the user.points field. You need a transaction log:
loyalty_transactions:
id UUID PK
user_id UUID FK
type ENUM('earn', 'redeem', 'expire', 'refund', 'bonus')
amount INTEGER -- positive for earn, negative for redeem
reference_id UUID -- purchase_id, action_id
reference_type VARCHAR
expires_at TIMESTAMP -- for earn transactions
created_at TIMESTAMP
-- Balance = sum of amount from non-expired transactions
-- SELECT COALESCE(SUM(amount), 0) FROM loyalty_transactions
-- WHERE user_id = ? AND (expires_at IS NULL OR expires_at > NOW())
This enables: reversing credits on purchase refund, implementing expiry with transaction precision, auditing any balance changes.
All balance change operations — through database transaction with SERIALIZABLE isolation level for counters, or through optimistic locking. Without this, parallel requests (multiple tabs, repeated tap) can cause balance to go negative.
Credit mechanisms
Basic variants: per purchase (N points per unit), per action (registration, review, friend invitation), bonus periods (x2 on weekends). Each type — separate rule in loyalty_rules table with conditions and coefficients. This allows changing mechanics without deployment.
Fraud prevention: limit credits per action per time unit (rate limiting by user_id + action_type), verify actions (e.g., review counts only after moderation), limit referral credits.
Client implementation
On the mobile client — three key screens: balance with transaction history, rewards catalog, redemption screen. Balance synchronizes on every app open and through WebSocket/SSE during active operations.
// Swift — subscribe to balance updates via WebSocket
class LoyaltyViewModel: ObservableObject {
@Published var balance: Int = 0
@Published var transactions: [LoyaltyTransaction] = []
func subscribeToUpdates() {
webSocketService.subscribe(channel: "loyalty.\(userID)") { [weak self] event in
DispatchQueue.main.async {
self?.balance = event.newBalance
self?.transactions.insert(event.transaction, at: 0)
}
}
}
}
Loyalty program tiers
Tiered system (Bronze → Silver → Gold) requires recalculating tier on each balance change. Better to store total_earned (accumulated per period without deductions) separately from current balance — it's this value that determines the tier.
Tier reset dates (usually annually) — separate background task or cron. Need to notify users 30 days before tier downgrade.
Integration with IAP
On purchase through In-App Purchase: points are credited on the server after transaction verification, before finishTransaction on client you don't need to wait — points can be credited asynchronously. On refund through Apple/Google — handle webhook and create a refund transaction in the log.
Implementation time — approximately 5 days: schema design, server crediting and redemption logic, client screens, notifications.