Developing a Loyalty Program in a Mobile App

Many have faced situations where after a product return, the points balance goes negative, and parallel requests result in double points. These problems are a direct consequence of storing the balance in a single user.points field. Incorrect balance leads to customer churn and legal risks. Over 20+ projects in fintech and retail, we have developed an architecture that eliminates such scenarios. Our solution is based on a transaction journal, tier system, and flexible rules that can be updated on the fly. Unlike storing balance in a single field, the journal ensures consistency and rollback capability — 50% higher reliability.

Why a Transaction Journal?

Instead of a single field, we maintain a loyalty_transactions table. Each accrual or deduction is a separate row with type, amount, and expiration. The balance is calculated as the sum of non-expired records. This allows rolling back erroneous operations, correctly handling returns, and eliminating discrepancies in parallel requests.

loyalty_transactions:
  id UUID PK
  user_id UUID FK
  type ENUM('earn', 'redeem', 'expire', 'refund', 'bonus')
  amount INTEGER
  reference_id UUID
  reference_type VARCHAR
  expires_at TIMESTAMP
  created_at TIMESTAMP

-- Balance = sum of amount over non-expired transactions
-- SELECT COALESCE(SUM(amount), 0) FROM loyalty_transactions
-- WHERE user_id = ? AND (expires_at IS NULL OR expires_at > NOW())

All changes go through a database transaction with isolation level SERIALIZABLE. This guarantees balance consistency under concurrent requests. In practice — none of our projects experienced discrepancies after implementation.

How to Set Up Accrual Mechanics Without Deployment?

The rules are stored in the loyalty_rules table on the server. Each record contains a condition and a coefficient. An administrator can change parameters through a control panel — for example, temporarily double points for purchases. Examples of rules:

• N points per purchase (configurable rate)
• Bonus for actions (registration, review)
• Temporary promotions (2x on weekends)
• Spending rules: minimum amount for redemption, category restrictions

To prevent abuse, we implement rate limiting, action verification, and referral accrual limits. The server-side loyalty logic remains centralized — changes take effect without requiring an app update.

Tier System: Bronze → Silver → Gold

The participant level is determined by total_earned — the sum of points earned over a period (excluding redemptions). Spending points does not lower the tier. Reset dates are annual, with a 30-day notice before downgrade.

Integration with In-App Purchase

Points accrual for purchases via IAP happens on the server after transaction verification. The client does not wait for a response — points arrive asynchronously via WebSocket. For refunds, we process the webhook from Apple/Google and create a refund transaction. Point transactions are fully synchronized with the payment system.

Client Side

On the mobile client — three screens: balance with history, rewards catalog, redemption screen. Balance is synchronized via WebSocket during active operations.

// Swift — subscription 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)
            }
        }
    }
}

Work Process

1. Analysis: study your business model and touchpoints.
2. Design: data schema, API, client screens.
3. Implementation: server logic, integration with payment systems.
4. Testing: load testing, race condition checks.
5. Deployment: deploy to production, hand over documentation.

Timelines and Cost

Cost is calculated individually. Thanks to ready components, budget savings can reach 30% compared to development from scratch. Get a consultation for an accurate estimate.

Typical Design Mistakes

• Storing balance in a single field — leads to discrepancies.
• Lack of transaction journal — impossible to rollback erroneous accruals.
• Ignoring parallel requests — double accruals.
• Tight coupling of rules to the client — every change requires deployment.
• No expiry of points — uncontrolled growth of liabilities.

What's Included in the Work

We provide:

• Database schema and transaction journal
• Server logic for accrual and redemption (Docker, REST API)
• Client screens (SwiftUI / Jetpack Compose)
• Integration with App Store / Google Play (verification, webhook)
• Push notifications about accruals, downgrades
• Administrative panel for managing rules
• API documentation and administrator manual

We have developed loyalty programs for fintech, retail, and gaming applications. We take into account App Store Review Guidelines (Section 4.2, 5.1) at the design stage. Contact us to discuss your task.

Mobile App Monetization: IAP, Subscriptions, and Ad Mediation

An app with poorly implemented purchases loses money not because users don't want to pay, but because a StoreKit transaction hangs, Receipt Validation fails with an error, or restore purchases doesn't work — and the user writes to support or leaves a 1-star review. Our experience (over 7 years in mobile development) shows that proper monetization increases LTV by 30–60% within the first three months after implementation. Get a consultation on monetizing your app — we'll analyze the current model and find growth points.

Why StoreKit 2 is the Best Choice for IAP?

StoreKit 2 (iOS 15+) is a modern API with async/await and device-side verified transactions without a server. Transaction.currentEntitlements returns all active purchases. Key change compared to StoreKit 1: JWS signature verification on device via VerificationResult<Transaction> — no need to send receipt to server for basic validation.

But server-side validation is still needed for consumable purchases and fraud prevention. App Store Server API replaces the old /verifyReceipt endpoint. Webhooks via App Store Server Notifications v2 provide real-time events: SUBSCRIBED, DID_RENEW, EXPIRED, REFUND — without polling.

A typical mistake: not handling paymentQueue(_:updatedTransactions:) in the background for unfinished transactions. User bought a consumable, app crashed before finishTransaction — purchase remains in queue, restores on next launch and requires reprocessing on server. Without server idempotency — double crediting.

How Not to Lose Revenue on Subscriptions?

The subscription model requires tracking states: trial → active → grace period → expired → refunded. RevenueCat is the de facto standard for managing subscriptions in production. It abstracts StoreKit and Google Play Billing, providing a unified API, webhooks, cohort analytics, and A/B testing of paywalls.

Alternatives to RevenueCat include custom implementations with Adapty or Qonversion. Fully custom only if data must not leave the infrastructure or there is non-standard logic. We guarantee that webhook setup and subscription lifecycle event handling is done without losses — verified on projects with over 500k DAU.

Google Play Billing Library 6+ requires handling PurchasesUpdatedListener and explicitly calling acknowledgePurchase() or consumePurchase() within 3 days — otherwise Google automatically cancels the purchase and refunds. The average cost of such an error is a significant loss per user per month (based on our project data).

Ad Mediation: Boosting CPM via Bidding

Showing ads from a single source means losing revenue. Mediation (waterfall or bidding) requests ads from multiple networks and displays the best bid. Google AdMob is the foundation for banner, interstitial, rewarded ads. Mediation via AdMob Mediation or MAX (AppLovin) is the second de facto standard. MAX uses In-App Bidding — a real-time auction without waterfall. In practice, MAX yields significantly higher CPM than classic waterfall (depending on geo and audience). For example, for rewarded video in the US, the improvement can be substantial. With 100,000 rewarded video impressions per day, switching from waterfall to In-App Bidding can generate additional daily revenue.

ironSource (Unity Ads) has a strong position in the gaming segment, especially rewarded video. Mintegral covers the Asian audience well.

Setting up mediation requires ATT (App Tracking Transparency) on iOS 14+. Without requestTrackingAuthorization, ad CPM drops by 3-5 times for non-consenting users. SKAdNetwork and Privacy Manifest (iOS 17) are mandatory requirements; without them, review fails.

How We Implement Monetization: Step-by-Step Process

1. Current model audit — analysis of funnel, paywall, price tiers, and identification of bottlenecks.
2. Model design — choose type (subscription, consumable, non-consumable) and optimize price points.
3. IAP integration — set up StoreKit 2 / Google Billing 6, receipt validation, webhooks.
4. Ad mediation — connect 3-6 networks, configure waterfall or In-App Bidding, test fill rate.
5. Analytics and cohorts — integrate RevenueCat, Amplitude, or Firebase for LTV tracking.
6. A/B testing of paywall — use Remote Config for experiments without a release.
7. Launch and monitoring — 2 weeks of free support after launch, bug fixes by 24-hour SLA.

How to Design a Freemium Model and Paywall?

Freemium works when the boundary between free and paid is properly drawn. Too strict a paywall at the start — users delete. Too generous a free tier — no incentive to pay.

A technically sound pattern: server-side feature flags (Remote Config in Firebase or LaunchDarkly) control access to features. This allows A/B testing of paywall without a release, changing trial conditions, and running promotions.

Implementation at the code level: EntitlementManager — a single point for checking access to features, aware of subscription status, flags, and promos. No scattered isPremium checks throughout the code. Experience shows this approach reduces paywall-related bugs by 80% (confirmed on 30+ projects).

Scope of Monetization Work

• Current model audit — analysis of funnel, paywall, price tiers.
• IAP integration — StoreKit 2 / Google Billing 6, receipt validation, webhooks.
• Ad mediation — configure MAX / AdMob, connect 3-6 networks, test fill rate.
• Analytics setup — RevenueCat, Amplitude / Firebase, cohort analysis.
• Documentation — description of entitlements, restoration procedure, review checklist.
• Team training — analysis of typical mistakes, support recommendations.
• Guarantee — 2 weeks free support after launch, bug fixes by 24-hour SLA.

Estimated Timelines

Cost is calculated individually. We have been working in this field for over 8 years and have implemented monetization in over 40 projects — many of which passed App Store Review without a single rejection. Contact us for an audit or order a consultation — we'll tell you what growth points exist in your app.