DEV Community

Cover image for How to Design a Subscription System for Mobile Apps: Architecture, Payments, and User Entitlements
Synfinity Dynamics Pvt Ltd
Synfinity Dynamics Pvt Ltd

Posted on

How to Design a Subscription System for Mobile Apps: Architecture, Payments, and User Entitlements

#mobile #flutter #backend #stripe

Mobile app subscriptions have become one of the most popular monetization strategies for modern applications.

From fitness apps and productivity tools to AI assistants, streaming platforms, and SaaS applications, subscriptions allow businesses to generate recurring revenue instead of relying only on one-time purchases or advertisements.

However, implementing subscriptions is not as simple as adding a “Subscribe Now” button.

A production-ready subscription system needs to handle:

  • Payment processing
  • Subscription verification
  • Plan management
  • Renewals
  • Expiration
  • Cancellation
  • Refunds
  • Premium feature access
  • Multiple payment providers

A poorly designed subscription system can lead to incorrect user access, revenue loss, payment disputes, and difficult maintenance.

This article explains how to design a scalable mobile app subscription architecture, including payment flow, database design, and entitlement management.

Understanding Mobile App Subscription Architecture

A subscription system usually involves multiple layers working together:

User
  |
  ↓
Mobile Application
  |
  ↓
App Store / Google Play Billing
  |
  ↓
Backend Server
  |
  ↓
Subscription Database
  |
  ↓
Entitlement System
  |
  ↓
Premium Features
Enter fullscreen mode Exit fullscreen mode

Each layer has a different responsibility.

Mobile Application

The mobile app is responsible for:

  • Showing available plans
  • Starting the purchase process
  • Displaying subscription status
  • Restricting user interface elements

However, the app should not be responsible for deciding whether a user is premium.

Payment Provider

The payment platform handles:

  • Payment collection
  • Transaction processing
  • Billing cycles
  • Renewal attempts

Examples:

  • Apple App Store
  • Google Play Billing
  • Stripe
  • RevenueCat

Backend Server

The backend is responsible for:

  • Verifying purchases
  • Storing subscription status
  • Processing subscription events
  • Controlling premium access

The backend should always be the source of truth.

Subscription vs One-Time Purchase

A one-time purchase and a subscription require completely different architectures.

One-Time Purchase

The flow is simple:

User pays
    ↓
Payment confirmed
    ↓
Feature unlocked permanently
Enter fullscreen mode Exit fullscreen mode

Example:

A user purchases a lifetime premium version.

The application only needs to know:

User purchased feature = true
Enter fullscreen mode Exit fullscreen mode

Subscription Model

Subscriptions are dynamic:

User subscribes
       ↓
Payment repeats
       ↓
Subscription status changes
       ↓
Access updates automatically
Enter fullscreen mode Exit fullscreen mode

The system must handle:

  • Active subscription
  • Renewal
  • Cancellation
  • Expiration
  • Failed payment
  • Refunds
  • Trial periods

This is why subscription systems need stronger backend architecture.

Designing the Subscription Database Model

A scalable subscription system should separate users, plans, subscriptions, and features.

A basic database structure can look like this:

Users Table 

users
----------------
id
email
created_at
Enter fullscreen mode Exit fullscreen mode

Stores user identity information.

Subscription Plans Table 

subscription_plans
-------------------
id
name
price
billing_period
Enter fullscreen mode Exit fullscreen mode

Example:

Monthly Premium
$9.99
30 days
Enter fullscreen mode Exit fullscreen mode

or

Annual Premium
$99.99
365 days
Enter fullscreen mode Exit fullscreen mode

User Subscription Table 

subscriptions
--------------
id
user_id
plan_id
status
start_date
expiry_date
provider
transaction_id
Enter fullscreen mode Exit fullscreen mode

Example:

user_id:
123

plan:
Premium Monthly

status:
active

expiry:
2026-10-10
Enter fullscreen mode Exit fullscreen mode

This table represents the current subscription state.

Why User Entitlements Matter

A common mistake is connecting features directly to subscription plans.

Example:

Premium Plan
     |
     ↓
Show AI Feature
Enter fullscreen mode Exit fullscreen mode

This becomes difficult when products grow.

A better approach is an entitlement system.

Architecture:

Subscription Plan
        |
        ↓
Entitlements
        |
        ↓
Feature Access
Enter fullscreen mode Exit fullscreen mode

Example:

Premium Plan:

AI Chat
Unlimited Projects
Export Data
Advanced Analytics
Enter fullscreen mode Exit fullscreen mode

Now if the company creates a new plan:

Professional Plan
Enter fullscreen mode Exit fullscreen mode

it can reuse existing entitlements.

Benefits:

  • Easier plan changes
  • Flexible pricing models
  • Multiple subscription providers
  • Cleaner backend logic

Mobile Subscription Purchase Flow

A typical subscription purchase works like this:

User clicks Subscribe

        ↓

Mobile app starts purchase

        ↓

App Store / Google Play processes payment

        ↓

Purchase token generated

        ↓

Backend verifies transaction

        ↓

Subscription activated

        ↓

Premium features unlocked
Enter fullscreen mode Exit fullscreen mode

The important part is verification.

The mobile app should never directly decide:

Payment successful = premium user
Enter fullscreen mode Exit fullscreen mode

because client-side data can be modified.

Backend Subscription Verification

After purchase, the backend should verify the transaction.

The verification process checks:

  • Product ID
  • User identity
  • Transaction ID
  • Purchase status
  • Expiration date
  • Renewal information

Example:

Mobile App

    |
    |
Purchase Token

    |
    ↓

Backend

    |
    ↓

Google Play / Apple Verification API

    |
    ↓

Valid?

    |
    ↓

Update Subscription Database
Enter fullscreen mode Exit fullscreen mode

Only after successful verification should premium access be enabled.

Handling Subscription Lifecycle Events

Subscriptions are not a single event.

They continuously change.

A good system handles every state.

Successful Renewal

Example:

Subscription expires:
10 September

Renewal successful:

New expiry:
10 October
Enter fullscreen mode Exit fullscreen mode

Backend updates:

status = active
expiry_date = new date
Enter fullscreen mode Exit fullscreen mode

Cancellation

Cancellation does not always mean immediate removal.

Usually:

User cancels subscription

        ↓

Access continues until expiry

        ↓

Subscription ends
Enter fullscreen mode Exit fullscreen mode

Example:

A user cancels on September 5.

Their plan expires on September 30.

They should still have premium access until September 30.

Failed Payment

Example:

Payment failed

      ↓

Grace period

      ↓

Retry payment

      ↓

Subscription expires
Enter fullscreen mode Exit fullscreen mode

The system should not immediately remove access after one failed payment.

Refunds

When a refund occurs:

Store sends refund event

        ↓

Backend updates subscription

        ↓

Remove entitlement
Enter fullscreen mode Exit fullscreen mode

Using Webhooks for Subscription Updates

A subscription system should not continuously check payment providers.

Instead, use webhooks.

Flow:

Apple / Google

       ↓

Webhook Event

       ↓

Backend

       ↓

Update Subscription

       ↓

Update User Access
Enter fullscreen mode Exit fullscreen mode

Examples of webhook events:

  • Subscription renewed
  • Subscription cancelled
  • Payment failed
  • Refund completed
  • Trial ended

Benefits:

  • Real-time updates
  • Less API usage
  • More reliable state management

Managing Premium Feature Access

A common mistake is handling premium access only in the frontend.

Example:

if(user.isPremium){
    showFeature();
}
Enter fullscreen mode Exit fullscreen mode

This is insecure.

Users can modify application data.

A better approach:

User requests feature

        ↓

Backend checks entitlement

        ↓

Allow or reject request
Enter fullscreen mode Exit fullscreen mode

Example API:

GET /user/features
Enter fullscreen mode Exit fullscreen mode

Response:

{
 "premium": true,
 "features": [
   "ai_chat",
   "export",
   "analytics"
 ]
}
Enter fullscreen mode Exit fullscreen mode

The backend controls access.

Supporting Multiple Subscription Providers

Many applications support multiple payment sources:

  • Apple subscriptions
  • Google Play subscriptions
  • Stripe subscriptions

Instead of creating separate logic:

Apple Code
Google Code
Stripe Code
Enter fullscreen mode Exit fullscreen mode

Create a unified subscription service.

Architecture:

Apple
Google
Stripe

   ↓

Subscription Service

   ↓

Entitlement System
Enter fullscreen mode Exit fullscreen mode

Now the application only understands:

User has entitlement X
Enter fullscreen mode Exit fullscreen mode

not:

User paid through provider Y
Enter fullscreen mode Exit fullscreen mode

This makes future expansion easier.

Common Subscription Implementation Mistakes

1. Trusting Mobile Purchase Response

Problem:

The client says:

Payment successful
Enter fullscreen mode Exit fullscreen mode

and immediately unlocks features.

Solution:

Always verify purchases on the backend.

2. Storing Only Premium Status

Bad:

user:
premium = true
Enter fullscreen mode Exit fullscreen mode

Problem:

You cannot know:

  • Expiry date
  • Renewal status
  • Cancellation state

Better:

subscription:
status
start_date
expiry_date
provider
Enter fullscreen mode Exit fullscreen mode

3. Hardcoding Features

Example:

if(plan=="premium"){
 enableAI();
}
Enter fullscreen mode Exit fullscreen mode

Problem:

Every pricing change requires code changes.

Solution:

Use entitlement-based access.

4. Ignoring Failed Payments

Problem:

Users may continue using premium features without successful payment.

Solution:

Handle:

  • Retry periods
  • Grace periods
  • Expiration

Scaling Subscription Systems

For large applications, subscription processing should be event-driven.

Example:

Webhook

   ↓

Message Queue

   ↓

Subscription Worker

   ↓

Database Update

   ↓

Cache Refresh
Enter fullscreen mode Exit fullscreen mode

Important practices:

Idempotent Processing

The same webhook event may arrive multiple times.

Your system should avoid duplicate processing.

Example:

transaction_id already processed

       ↓

Ignore duplicate event
Enter fullscreen mode Exit fullscreen mode

Subscription History

Do not only store the current state.

Maintain history:

subscription_events

-------------------

created

renewed

cancelled

expired

refunded
Enter fullscreen mode Exit fullscreen mode

This helps with:

  • Customer support
  • Debugging
  • Revenue analysis

Subscription Analytics and Metrics

Building subscriptions is only half the challenge.

You also need to measure performance.

Important metrics:

Monthly Recurring Revenue (MRR)

Total predictable monthly subscription revenue.

Churn Rate

Percentage of users who cancel subscriptions.

Conversion Rate

Percentage of free users who become paying customers.

Customer Lifetime Value (LTV)

Estimated revenue generated from one customer.

Tracking these metrics helps teams improve:

  • Pricing
  • Features
  • Onboarding
  • Retention

Final Thoughts

A subscription system is not just a payment integration.

It is a complete architecture involving:

  • Payment providers
  • Backend verification
  • Subscription databases
  • Entitlement management
  • Webhooks
  • Feature access control
  • Analytics

A scalable subscription system should:

  • Never trust only the client
  • Verify payments on the backend
  • Separate plans from features
  • Handle every subscription lifecycle event
  • Support future payment providers
  • Keep subscription history

The goal is not only to collect payments.

The goal is to build a reliable system that manages the complete relationship between users, payments, and premium features.

How are you handling subscriptions in your mobile applications — native billing, Stripe, or a service like RevenueCat?

📚 Related Reading

Top comments (0)