A Subscription Mobile Game Platform with Full Store Lifecycle Management

Delivered remotely for a business based in Abu Dhabi, United Arab Emirates. Names withheld by agreement.

Project Overview

Industry: Consumer mobile gaming and sports performance tracking.

Type of solution: A cross-platform mobile application over a REST API and administrative platform, monetised through recurring in-app subscriptions on both major app stores.

Business context: Subscription is now the default model for consumer mobile products, and it moves the hardest part of the business outside the application. The stores own the billing relationship. They renew, they retry failed payments, they issue refunds, they apply grace periods, they process cancellations that take effect weeks later — and they do all of it whether or not the user has opened the app since. An application that treats entitlement as something the client tells it will be wrong regularly, in both directions, and every instance of being wrong is either lost revenue or a support ticket from someone who has paid.

General users: Players, who configure and play rounds against virtual opponents and track their scoring; and administrators, who tune game rules, manage virtual opponents, oversee subscriptions and manage content.

General purpose: To deliver a satisfying, tunable sports game experience on mobile, funded by a subscription model that reconciles accurately with both app stores.

The Business Challenge

Entitlement lives outside the product. The application cannot know from its own data whether a user is currently entitled to access. That truth sits with Apple and Google, changes without any user action, and must be actively reconciled.

Two stores, two completely different mechanisms. Apple sends server-to-server notifications to a webhook. Google publishes to a cloud messaging topic requiring a consumer to pull from it. The data shapes, event vocabularies and delivery semantics differ. Both have to end up as one internal subscription state.

Client-reported purchases cannot be trusted. Anything the app claims about a purchase must be validated server-side against the issuing platform, or the entitlement model is only as strong as the device it runs on.

Notifications get missed. Webhooks fail, consumers fall behind, messages arrive out of order. An event-driven design alone will drift out of sync, and the drift will be invisible until a customer complains.

Expiry is a timezone problem. Comparing an expiry timestamp in the wrong timezone produces access decisions that are wrong by hours — always at the boundary, always noticed.

The game had to be tunable. Difficulty, distances, scoring and putting outcomes needed adjusting repeatedly after real players arrived. Every adjustment requiring a code change and store review would have made balancing the game impossible in practice.

Opponents needed to be credible. A single-player game needs opposition that is competitive but beatable, and that varies by game format — otherwise it is either discouraging or trivial.

Registration had to be low-friction but verified. Both email and phone sign-in with one-time codes, without letting SMS delivery become a single point of failure at the front door of the product.

Our Approach

Build subscription reconciliation as a subsystem, not a feature. We designed the subscription layer as its own architectural component with multiple independent entry points converging on one state model: purchase verification at the moment of sale, platform notification handling from both stores, queued asynchronous verification, and a scheduled sweep that reconciles regardless of what arrived by other routes. Redundancy here is deliberate — each path covers the others' failure modes.

Verify server-side, always. Receipts are validated against Apple and Google directly, through dedicated verification services per platform. The application's entitlement decision never depends on what the client reports.

Normalise two platforms into one model. Apple's webhook events and Google's published notifications are translated into a single internal subscription representation carrying platform, platform subscription identifier, original transaction identifier, renewal state, status and expiry — so the rest of the application reasons about subscriptions without knowing which store they came from.

Keep the evidence. Every transaction retains the full raw platform payload alongside typed fields. When a billing question arises months later, the original response is available rather than reconstructed.

Store expiry with its timezone. A small decision that eliminates an entire category of access bugs that are invisible in testing.

Make the game rules data. Difficulty tiers, distances, pars, terrain, break and putting outcome tables are all administratively managed reference data. Game balance became something the operator tunes based on how real players perform, in minutes, rather than a development and store review cycle.

Model opponents as data too. Virtual opponents carry their own scoring profiles, applicable game formats, status and presentation, so new opposition can be introduced without a release.

Build redundancy into the front door. Two SMS providers back the one-time code path, because a delivery failure at registration is a permanently lost user rather than an inconvenience.

The Solution

Flexible game configuration. Players set up a round by choosing the number of players and rounds, difficulty, course context and format, with the configuration determining how scoring and opponents behave.

Virtual opponents. Configurable computer opponents with their own scoring profiles across the front nine, back nine and total, applicable to specific game formats, presented with their own identity — providing structured competition in a single-player experience.

Detailed shot and putt modelling. Scoring accounts for the factors that decide real outcomes — distance, terrain, break and difficulty — combined through administratively maintained reference data so results feel plausible and can be tuned.

Hole-by-hole scoring and scorecards. Play is recorded at hole level, producing scorecards per round with result determination per game and history preserved rather than overwritten.

Multiple game formats. Game type variants apply across scoring, pars and opponents, so the same underlying engine supports several ways to play.

Subscription access. Access is governed by recurring subscription purchased through the app stores, with plans retrieved from the platforms rather than hard-coded, so store-side changes do not require an app release.

Accurate entitlement. Subscription state is reconciled continuously through platform notifications, verification at purchase, asynchronous re-verification and a scheduled sweep — so what the app grants matches what the store says.

Dual sign-in with one-time codes. Registration and login by email or phone number with international number handling and one-time code verification, backed by two independent SMS providers.

Profile management. Profile creation and editing with image upload and cropping.

Administrative tuning platform. Administrators manage every reference data set — difficulty, distances, pars, putting terrain, break and result tables — plus virtual opponents, plans, users, content and dashboards. Game balance is operational configuration rather than engineering work.

Key Features

Multi-path subscription reconciliation Purchase verification, Apple server notifications, Google real-time notifications, queued re-verification and a scheduled sweep all converge on one subscription state, so no single failed delivery causes entitlement drift.

Server-side receipt verification for both stores Dedicated verification services validate purchases directly with Apple and Google, so entitlement never depends on what the client claims.

Full platform payload retention Every transaction stores the raw platform response alongside typed fields including original transaction identifier and notification type, preserving evidence for later billing questions.

Timezone-correct expiry handling Expiry stored with its timezone, eliminating boundary access errors that testing rarely catches.

Store-fetched subscription plans Plans are retrieved from the platforms rather than hard-coded, so pricing and product changes made store-side take effect without an app release.

Data-driven game balance Difficulty, distances, pars, terrain, break and outcome tables are administratively managed, making game tuning a configuration task rather than a development cycle.

Configurable virtual opponents Opponents carry their own scoring profiles, applicable formats and presentation, so new competition can be added as data.

Hole-level scoring with preserved history Scoring recorded per hole with soft deletion, producing scorecards and result determination while retaining play history.

Dual authentication with redundant delivery Email and phone sign-in with one-time codes and international phone handling, backed by two independent SMS providers so registration does not depend on a single vendor.

Multiple game formats on one engine Game type variants applied across scoring, pars and opponents, supporting several ways to play without duplicating the underlying model.

Technical Architecture

Mobile client. A cross-platform application with a predictable state container, screen-per-flow navigation, environment-based configuration, and dedicated components for one-time code entry, international phone input, media capture with cropping and in-app messaging.

API layer. A token-authenticated REST API with controllers separated between player-facing operations and administrative reference data management, over shared base classes.

Subscription subsystem. The architectural centrepiece, composed of platform-specific verification services, a plan fetcher, a cloud messaging consumer, a webhook endpoint, a queued verification job and a scheduled reconciliation command — multiple independent entry points resolving to one subscription state model.

Game engine layer. Scoring and outcome resolution driven by reference data tables rather than hard-coded constants, with virtual opponent behaviour likewise held as data.

Data layer. A relational database holding users, subscriptions and transactions alongside game configuration, reference data, scores and scorecards, with soft deletion preserving play history.

Asynchronous processing. Queued jobs for verification work and scheduled commands for reconciliation and notification consumption, keeping this work off the request path.

External services. Both app store platforms for purchase verification and notifications, a cloud messaging service as the notification transport for one platform, cloud object storage for media, and two SMS providers for one-time codes.

Flow: Mobile app → Token-authenticated API → Game engine over reference data → Relational database → Subscription subsystem ⇄ App store verification & notifications (webhook + cloud messaging) → Queued verification + scheduled reconciliation → Entitlement state

Technology Stack

Technical Challenges & Solutions

Security & Reliability

Authentication. Token-based OAuth2 authentication with both email and phone sign-in paths, each verified — email through a verification flow and phone through one-time codes.

Entitlement integrity. Purchases are validated server-side against the issuing platform. The application never grants access on the basis of client-reported purchase state.

Platform notification handling. Server-to-server notifications from both stores are consumed and applied to subscription state, keeping entitlement current without depending on user activity.

Reconciliation redundancy. A scheduled sweep operates independently of notification delivery, so missed or delayed events are corrected rather than persisting as silent drift.

Evidence retention. Raw platform payloads and platform transaction identifiers are stored, providing a verifiable record for billing investigation and dispute resolution.

Surface separation. Player-facing and administrative controllers are kept separate, so reference data and user management are not reachable from the player API.

Non-destructive history. Soft deletion on scoring records preserves play history rather than discarding it.

Delivery redundancy. Two SMS providers on the verification path reduce dependence on a single vendor at the most critical moment in the user journey.

Scalability & Performance

Asynchronous verification. Subscription verification runs as queued work rather than inside user-facing requests, so purchase flows stay responsive regardless of platform API latency.

Buffered notification transport. Platform notifications are consumed from a cloud messaging service, which absorbs delivery spikes rather than pushing them directly into the application.

Scheduled batch reconciliation. Periodic subscription checking runs as a scheduled command, keeping this work entirely off the request path.

Small, cacheable reference data. Game rules live in compact reference tables that are read frequently and change rarely — inexpensive to serve and simple to cache.

Externalised media storage. Profile imagery is held in cloud object storage rather than on application servers, keeping instances stateless.

Single mobile codebase. One cross-platform application serves both platforms, so feature delivery and store lifecycle handling are implemented once.

Business Outcomes

• Revenue is protected in both directions — the platform does not grant access it is not paid for, and does not revoke access from customers who are paying.
• Entitlement stays current without user activity, because platform notifications and scheduled reconciliation keep subscription state accurate whether or not the app is opened.
• Billing questions can be answered from evidence, since raw platform responses and transaction identifiers are retained.
• Store-side pricing changes need no app release, because plans are fetched from the platforms.
• The game can be balanced against real player behaviour, in minutes, because rules are configuration rather than code.
• New opponents and formats ship without a release, since both are data-driven.
• Registration is resilient, with two independent SMS providers on the one-time code path.
• One codebase serves both platforms, keeping a subscription consumer product economically viable.

Why it worked

Most subscription apps implement the happy path: the user buys, the app checks a receipt once, and access is granted. That works until the first renewal, the first refund, the first failed payment, the first cancellation that takes effect in three weeks. Then the product starts being wrong about who is entitled — sometimes losing money, sometimes losing customers — and nobody notices until the support queue fills up.

Our team builds the part that most teams discover too late. We treat subscription reconciliation as a subsystem with redundant entry points, because platform notifications fail and event-driven designs drift. We verify server-side, because client-reported entitlement is not entitlement. We retain the raw platform evidence, because billing disputes arrive long after the transaction. And we handle the unglamorous details — timezone-correct expiry, platform-specific notification vocabularies, original transaction identifiers — that separate a subscription implementation that reconciles from one that approximately reconciles.

The same instinct shaped the product side: game rules and opponents built as configurable data rather than code, because a consumer game's balance is discovered from real player behaviour after launch, and any design that requires a store review cycle to adjust will not be adjusted often enough to matter.

Final Summary

A subscription consumer app has two products inside it. One is the experience users see. The other is the billing relationship, and it lives entirely outside the application — at the app stores, where renewals succeed, payments fail, refunds are issued, grace periods apply and cancellations take effect on a schedule nobody in the business controls. Most subscription apps implement the purchase and assume the rest, then spend years being subtly wrong about who is entitled to what.

Our team built both properly. The subscription subsystem reconciles through five independent paths — verification at purchase, server notifications from Apple, real-time notifications consumed from Google through a cloud messaging transport, queued asynchronous re-verification, and a scheduled sweep that corrects whatever the other paths missed. Receipts are validated server-side against each platform, raw payloads are retained for later dispute resolution, expiry is stored with its timezone, and plans are fetched from the stores so pricing changes need no release.

The game itself was built on the same principle of keeping decisions changeable: difficulty, distances, scoring, terrain and putting outcomes are administratively managed reference data, and virtual opponents carry their own scoring profiles as records rather than code. Balance is tuned against how real players actually perform, in minutes rather than release cycles. Delivered as one cross-platform mobile codebase over a Laravel API, it is a consumer subscription product where both the experience and the revenue behind it were engineered with equal care.