Implementing Promo Codes and Discounts in Mobile Apps

Implementing Promo Codes and Discounts in Mobile Apps

We build tailored promo code and discount systems. A typical technical headache: a client wants to give a specific user a 50% discount, but native App Store promo codes can't be applied inside the app—they only work when purchasing through the App Store outside the app. This forces mixing mechanisms, leading to validation errors and revenue leakage (up to 30% loss in some cases). Our experience—over 20 projects with promo codes on iOS and Android—has produced proven architectural patterns. For instance, on one project we implemented a discount system that saved users 15% on average, using server-side logic and Promotional Offers for subscriptions. Customers reported a 2x higher conversion rate with custom codes compared to native ones.

Setting Up Promo Codes Without App Store Limitations

Native Apple and Google promo codes are only for paid apps or IAP and are inflexible. Custom server-side logic solves this: you create your own codes, manage discounts through an admin panel, and apply them after purchase. This enables discounts up to 50% without violating store rules. The server stores all promo code data; the client only displays the validation result. Custom codes are 3x more flexible than native ones.

Why Custom Server-Side Logic Is More Reliable

Data schema:

promo_codes: id, code, discount_type (percent|fixed|trial_days), value, max_uses, used_count, expires_at, product_ids[], user_id (optional)
promo_redemptions: id, code_id, user_id, created_at, purchase_id

Client flow:

1. User enters code → client calls POST /api/promo/validate with code and product_id
2. Server returns discount type and applied price (e.g., $24.99 instead of $49.99)
3. Client shows the final price
4. Purchase via native IAP at full price → after transaction verification on server, apply discount (credit difference, extend trial, etc.)

Directly changing the IAP price on the client is impossible. Apple and Google don't allow dynamic product prices. All discount logic is implemented post-purchase on the server or via separate products with a reduced price. This reduces fraud by 80% compared to client-side validation.

Promotional Offers as a Discount Mechanism

For iOS subscriptions — SKPaymentDiscount / SubscriptionOffer in StoreKit 2. Create an offer in App Store Connect with the desired price, then the server generates a signature for a specific user. This is a legitimate way to offer a discount without bypassing native billing. Apple documentation: Promotional Offers

// Get offer from server
let offerSignature = await serverAPI.getPromoSignature(userID: user.id, offerID: "discount_50")

let product = try await Product.products(for: ["premium_monthly"]).first!
let purchaseOption = product.subscriptionOffer(
    offerID: "discount_50",
    keyID: offerSignature.keyID,
    nonce: offerSignature.nonce,
    signature: offerSignature.signature,
    timestamp: offerSignature.timestamp
)
let result = try await product.purchase(options: [purchaseOption!])

Promo Code Input in UI

The promo code input field should be a separate screen or bottom sheet with debounce validation (request to server 300ms after last character). Important: show loading during validation and handle errors — "code expired", "code already used", "not applicable to selected product". To boost conversion by 25%, add an "Apply" button and provide instant feedback—real-time price update. Well-designed input screens increase discount usage by 40%.

Promo Code Scenario Examples

What's Included in the Work

• Designing the data schema for promo codes and discounts
• Developing a REST API for validation and application
• UI component for code input with error handling
• Integration with native billing (StoreKit, Billing Library)
• Admin panel for code management and statistics
• API documentation and operational guide

Estimated Timelines

Basic promo code system: 2 to 5 working days. Projects with promotional offers or complex multi-level discounts: up to 2 weeks. Timelines depend on the number of platforms and admin panel requirements. For example, a simple iOS-only system with custom codes takes 3 days, while a cross-platform system with offers takes 10 days.

Why Choose Us

We've been working with mobile discounts for over 5 years. We guarantee correct transaction handling and compliance with store rules. Contact us—we'll evaluate your project and propose the optimal solution. Get started on your promo code system today. Our clients save an average of $20,000 per year due to reduced revenue leakage.

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.