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.
More on rate limiting
We use a bucket algorithm with a limit of 5 requests per second per user for accrual operations. The idempotency key is stored in Redis with a TTL of 120 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.
| Animation Type | iOS | Android |
|---|---|---|
| Coin flight | CAEmitterLayer + CAKeyframeAnimation | Canvas + ObjectAnimator |
| Odometer counter | AnimatedNumberView (SwiftUI) | ValueAnimator + TextSwitcher |
Why Server-Side Ledger is More Reliable than Client-Side?
| Aspect | Server-side ledger | Client-side balance |
|---|---|---|
| Atomicity | Guaranteed (DB transactions) | Race condition risk |
| Security | Protected by server validation | Easily modifiable |
| Audit | Full operation history | No trusted journal |
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
- Get receipt (iOS) or purchase token (Android) on the client.
- Send to our server (POST /validate-purchase).
- Server makes HTTP request to Apple Verify Receipt or Google Play Developer API.
- On successful validation, credit coins in the ledger and return confirmation.
- 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.