How ShareChat rebuilt subscription billing on Temporal and reached 99.9% reliability

The Customer

ShareChat (Mohalla Tech Pvt Ltd) is one of India’s largest homegrown social media company, with 325+ million MAUs across all its platforms across multiple regional Indian languages. Alongside the core feed, ShareChat provides a range of paid subscription products spanning multiple plans and price points across multiple products.

Every paid subscription on the platform, across products and plans essentially flows through a single Temporal-based billing engine.

The Challenge

Recurring subscription billing in India is deceptively complex. A single billing cycle has to send a mandated pre-debit notification, wait a regulator-defined window, then attempt collection by coordinating with third-party payment vendors (e.g. Paytm, PhonePe) whose calls can fail or return ambiguous "pending" states at any point. We also had to follow strict rate limiting as well as avoid debit attempts during peak hours as mandated by NPCI.

ShareChat's earlier approach relied on cron jobs to drive these cycles. That model struggled with the reliability, sequencing, and auditability that subscription-scale billing demands:

Each subscription was orchestrated using 4 cron jobs:

• Notify job was responsible for pre-debit notification via the payment vendor. It was followed by a VerifyNotify job which confirmed the notification was sent successfully. In case of failures in any of the steps, they were retried by creating a new Notify/VerifyNotify job in the database.
• Collect job was responsible for debit attempts making sure the debit attempts are happening in the hard-coded slots. Similar to Notify, this was followed by the VerifyCollect job which confirmed the debit attempt success or failure. Here any failures required the retry to be done the next day (hardcoded delay).
• Since Notify and Collect were created simultaneously, any prolonged failure in Notify step, lead to scenarios where debit attempts were being made without a notification leading to failures which could have been avoided.

Issues with the cron jobs

• Strict regulatory timing was hard to guarantee. RBI rules require a pre-debit notification at least 24 hours before any collection, and cap collection retries per notification. Enforcing this reliably across millions of subscriptions on cron was fragile and led to debit attempts without notification, which were rejected by Payment Gateways and never reached users, leading to drop in attempt rates.
• Failures left cycles in an indeterminate state. A vendor API failure or a mid-cycle crash could leave a billing attempt in an unclear state, risking missed collections or, worse, duplicate debits.
• Additionally, Cron jobs provided little observability into a subscription’s lifecycle and were hard to audit. Building the sequence of events for a subscription required a lot of work.
• ShareChat relies heavily on experiments to figure out optimal time to notify the users, and make debit attempts to avoid banks/PG downtimes while still following all the limitations around rate limits, avoid peak hours, etc. With cron jobs, running a new experiment required a lot of adhoc logic in code and metrics sanity required 2-3 days of work for each experiment.
• Retry and grace-period logic was implicit and hard to audit. Multi-attempt collection, per-notification retry caps, and post-exhaustion grace periods were difficult to model, change, and reason about on the old system.

The Solution

ShareChat rebuilt its subscription billing engine on Temporal, migrating off the legacy cron jobs. The engine is now the orchestration backbone for every subscription across the platform, built on the Go SDK.

Each subscription is modeled as a hierarchy of durable Temporal workflows:

• A top-level subscription orchestrator workflow runs in perpetuity for the life of the subscription and triggers the notify-and-collect child workflow for each billing cycle.
• The notify-and-collect child workflow encapsulates the full cycle: a notify-and-verify step (send the pre-debit notification via the payment vendor, then confirm it was sent, with infinite retries because the notification must go out), followed by a collect-and-verify step (attempt the debit, then confirm the outcome).
• The notify-and-collect child workflow also creates a retry notify-and-collect child workflow if it fails to debit the money within a configured time window.
• A durable timer (workflow sleep) enforces the configurable notify-to-collect delay (e.g. 25 hours + time to the nearest collect slot) so collection always lands the regulator-mandated time after notification and avoiding the peak hour as mandated by NPCI.
• When a notification's collection attempts are exhausted (capped at three per notification per RBI rules), a retry notify-and-collect workflow is spawned to begin a fresh notification-and-collect cycle, recursively, until a payment succeeds, retries are exhausted, or the subscription is cancelled. A configurable grace period keeps the user in service while late collection is retried before cancellation.
• Each notify-and-collect workflow resolves configs at the start of its execution. This means any requirement to run a new experiment is a simple config change instead of changing hardcoded code changes. With the new system, shipping a new experiment could be done in 30mins compared to multi-day effort in the cron jobs.

Why Temporal - Key capabilities Temporal provided:

• Durable execution without custom recovery code. Long-running billing workflows survive infrastructure failures and resume from the last committed step - no bespoke checkpointing for cycles that run for months.
• Durable timers for regulated sequencing. Workflow sleep enforces the notify-to-collect delay and per-day collection windows natively, with every delay configurable per plan.
• Signals for cross-cycle coordination. The orchestrator waits on a payment signal from the collect step before advancing to the next cycle.
• Workflow versioning for safe evolution. Because these are long-running workflows, ShareChat uses Temporal's workflow versioning to ship non-deterministic changes safely while older cycles continue running on prior versions. New experiment don’t impact old workflow runs since the configs are evaluated once at the start of every notification cycle.
• Full auditability. Every step of every billing cycle is recorded in Temporal's immutable workflow history as well as sent as events to internal data warehouse - valuable for dispute resolution, reconciliation against payment vendors as well as for analytics and more experiments
• Incremental, metrics-driven migration. ShareChat started the cron-to-Temporal migration in November 2025, moving subscription products across one at a time. As of April 2026 all subscription products run on Temporal Cloud. The rollout was deliberately paced, with each traffic increment gated on proper metrics sanity before the next.
• Purpose-built for recurring revenue. Subscription billing needs reliable, long-running, regulator-compliant coordination with external payment vendors. Temporal's ability to handle stateful, multi-month orchestration with durable timers and safe versioning made it the right foundation for recurring-revenue infrastructure.

Scale

• Every paid subscription across all ShareChat products flows through the Temporal engine.
• Sharechat, across all its products, runs about 450+ million actions per month on Temporal
• Every month ~50 Million transactions are attempted through this system for all subscription product offered by ShareChat

The Results

"With Temporal, launching new experiments is no longer an operational challenge. We’ve reduced the time from idea to production from multiple days to as little as 30 minutes, with far fewer post-launch issues to monitor" — Prarabdh Bharti, Engineering Manager - Payments, Mohalla Tech / ShareChat

• Debit Attempt rate went from ~95% to 99.9x%
• No lost or stuck cycles after failures. Durable execution means a vendor API failure or crash no longer leaves a billing cycle in an indeterminate state as the workflow resumes automatically.
• Regulatory timing enforced by design. The mandated notification-to-collection window and per-notification retry caps are guaranteed by durable timers and workflow logic rather than fragile cron scheduling.
• Full auditability out of the box. Every cycle's complete history lives in Temporal as well as sent as events to internal data warehouse - valuable for dispute resolution, reconciliation against payment vendors as well as for analytics and more experiments.

What's Next

Now Temporal is the default orchestrator for any new subscription product launched on the Platform. Onboarding a new product is a simple config adding for new subscription and can be done in as little as 30 mins.