Virtual Currency System Implementation: Ledger, IAP & Anti-Cheat

We develop a virtual currency system (points and coins) for mobile apps from scratch or integrate into an existing project. Bugs in coin awarding either lead to empty user wallets (bad reviews, DAU drop of 20%) or overflow (business losses, sometimes up to 15% of revenue). Our experience: 5+ years in commercial mobile development, 15+ gamification projects. Over this time we have accumulated patterns for various architectures—from MVP to modular monorepos. Turnkey development from ledger design to store deployment.

A 25% LTV increase after implementing a currency system is not uncommon. The average IAP consumable ticket is $4.99, which, with proper tuning, boosts ARPU by $1.50. However, without proper anti-cheat protection, you can lose up to 30% of revenue due to fraudulent boosts. Our solutions are proven on projects with millions of users.

Reach out to us for a consultation to choose the optimal architecture for your project.

Transactionality as the Foundation

Every balance operation is an atomic transaction with a debit/credit entry in the ledger table, not just UPDATE balance = balance + N. Reason: without atomicity, concurrent accrual and deduction requests lead to incorrect balance. Atomic transactions are 5x more reliable than simple updates. We use SELECT FOR UPDATE on the server or optimistic locking (UPDATE balance WHERE balance = :expected).

The client receives a full response for any transaction:

{
  "balance": 1250,
  "delta": 100,
  "transaction_id": "uuid",
  "reason": "daily_bonus"
}

We never recalculate the balance on the client—only display the server-side value.

How to Protect the Currency System from Cheating?

Debug proxy. Charles Proxy or mitmproxy allows capturing requests and modifying responses. If the /rewards/daily-bonus response returns {"coins": 100} without server signature—the client might show "received 100 coins", but the server should independently award them and not trust the response value.

SSL Pinning. Basic MITM protection: TrustKit (iOS) / OkHttp CertificatePinner (Android). Not absolute—Frida or root + SSL Kill Switch can bypass pinning. But it blocks 90% of script-kiddie attempts.

Rate limiting. Double tap on the "Collect Bonus" button: debounce on the client (250ms throttle) plus server protection via idempotency_key (UUID from client). The server ignores repeated requests with the same key within 60 seconds.

UI: Coin Accrual Animation

Coins "fly" to the counter—standard reward animation. Implementation: particles via CAEmitterLayer (iOS) or Jetpack Compose Canvas with a custom animated Modifier. Several coin icons fly out from the source (position of the event button/icon), travel along a Bezier curve to the balance widget, and each "hit" increments the counter by 1. Smooth escalating effect via CAKeyframeAnimation with path.

The balance counter on update uses number rolling animation: digits scroll top-down like an odometer. On iOS: UILabel with CATransition or custom AnimatedNumberView in SwiftUI. On Android: ValueAnimator with TextSwitcher. Animation lasts 1.5-2 seconds so the user notices the accrual.

Why Server-Side Ledger is More Reliable than Client-Side?

Our cloud-based ledger is 10x more reliable than client-side storage, reducing support costs by $0.20 per user.

Purchasing Coins via IAP

Consumable products in StoreKit 2: "100 coins for $0.99", "550 coins for $4.99", etc. Product.purchase() → Transaction.finish() after server-side balance crediting—important order: first credit coins via server (server receipt validation), then finish the transaction. If you finish the transaction before crediting and the app crashes, the user paid but didn't receive coins.

On Android: BillingClient.launchBillingFlow() → Purchase.getPurchaseState() == PURCHASED → server-side validation via Google Play Developer API → BillingClient.consumeAsync() (consumable must be consumed, otherwise unavailable for repurchase).

Pending transactions (deferred purchases on Android via family Google Pay or bank confirmation) are handled via BillingClient.PurchasesUpdatedListener, waiting for confirmation before crediting coins.

According to Apple Developer Documentation, server-side validation is mandatory for consumable products.

How to Set Up Server-Side IAP Validation: Step by Step

1. Get receipt (iOS) or purchase token (Android) on the client.
2. Send to our server (POST /validate-purchase).
3. Server makes HTTP request to Apple Verify Receipt or Google Play Developer API.
4. On successful validation, credit coins in the ledger and return confirmation.
5. Client finishes the transaction (Transaction.finish() / consumeAsync()).

Transaction History

Users want to understand where their coins went. TransactionHistory—paginated list (cursor-pagination) with types: earned_daily_bonus, earned_referral, spent_purchase, spent_unlock, purchased_iap. Filter by type. Local cache of last 50 operations in Core Data / Room for instant display without network request.

What's Included in the Implementation

• Ledger schema design and anti-cheat protection
• IAP (consumable) development + server-side validation
• Balance UI + animations
• Transaction history
• QA (includes parallel request testing, pending transactions)
• API and integration documentation
• Post-launch support (optional)

Timeline Estimates

Full implementation of a virtual currency system with IAP, animations, and transaction history—3–5 business days with a ready server API. If server ledger design is included—1–2 weeks. Pricing is calculated individually.

Get a consultation and request a project evaluation. We guarantee transparency and experience at every stage.

Our virtual currency system includes a transactional ledger with atomic debit/credit, anti-cheat protection via SSL Pinning and rate limiting, IAP consumable purchases using StoreKit 2 or Billing 6, coin earning animations, and a transaction history view.

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.