Your user’s credit card expires.

Their subscription renewal fails.

Your app does not know.

A few days later, the platform cancels the subscription. The user opens your app, finds that they have lost access, and leaves.

Not because they wanted to cancel.

Not because your product failed.

But because nobody told them to update their payment method.

This is involuntary churn — and for subscription-based apps, it is one of the most frustrating forms of churn because it is often recoverable.

The traditional solution is server-to-server notifications.

Apple sends your backend a webhook. Google sends your backend a real-time developer notification. Your backend updates the subscription state and, if you have the infrastructure in place, pushes a message back to the user.

That works.

But it also assumes you have backend infrastructure, webhook handling, notification delivery, retry logic, monitoring, and entitlement synchronization already set up.

Many indie developers and small teams do not.

So we shipped a different approach.

Introducing subscriptionBillingIssue

subscriptionBillingIssue is a client-side event that fires when an active subscription enters a billing-problem state.

No backend.

No webhook endpoint.

No server polling.

The app detects the billing issue directly from the platform billing SDK and can react immediately while the user is still inside the app.

The goal is simple:

Detect a failed subscription payment early enough that the user can fix it before they lose access.

How It Works

The implementation differs by platform, but the developer experience stays consistent across the OpenIAP ecosystem.

iOS 18+

On iOS 18 and later, Apple introduced the StoreKit 2 Message API.

This allows the system to deliver messages to the app while it is running. One of those messages is .billingIssue, which is triggered when the user has an auto-renewable subscription whose renewal failed.

OpenIAP listens for this message and checks the current subscription entitlements.

If a subscription is in either:

• inBillingRetryPeriod
• inGracePeriod

OpenIAP emits one subscriptionBillingIssue event for each affected subscription.

This gives the app a chance to show a user-facing prompt before the subscription fully expires.

Android — Play Billing 8.1+

On Android, Google added Purchase.isSuspended in Play Billing 8.1.

This flag indicates that a subscription has been suspended because of a payment failure.

OpenIAP checks this flag during:

• getAvailablePurchases
• onPurchasesUpdated

To avoid repeatedly showing the same warning, events are deduplicated by purchase token per app session.

So if the same suspended subscription appears multiple times during one session, the app only receives one billing issue event.

Meta Horizon / Quest

Meta Horizon currently uses the Horizon Billing Compatibility SDK, which targets Play Billing 7.0.

Because Play Billing 7.0 does not expose Purchase.isSuspended, billing issue detection is not available on Horizon yet.

The listener still exists for API parity, but calling it logs a warning and does nothing.

This is intentional and documented behavior.

What the Code Looks Like

React Native / Expo

import {
  subscriptionBillingIssueListener,
  deepLinkToSubscriptions,
} from 'react-native-iap'; // or 'expo-iap'

const subscription = subscriptionBillingIssueListener((purchase) => {
  Alert.alert(
    'Payment Issue',
    'Your subscription needs attention. Update your payment method to keep access.',
    [
      {
        text: 'Fix Now',
        onPress: () =>
          deepLinkToSubscriptions({
            skuAndroid: purchase.productId,
            packageNameAndroid: 'com.example.app',
          }),
      },
    ],
  );
});
// Cleanup
subscription.remove();

You can also handle the same event through the useIAP hook:

const { requestPurchase } = useIAP({
  onSubscriptionBillingIssue: (purchase) => {
    // Show your "fix payment" UI
  },
});

Flutter

final iap = FlutterInappPurchase.instance;

iap.subscriptionBillingIssueListener.listen((purchase) {
  showDialog(
    context: context,
    builder: (_) => AlertDialog(
      title: Text('Payment Issue'),
      content: Text('Update your payment method for ${purchase.productId}'),
      actions: [
        TextButton(
          onPressed: () => iap.deepLinkToSubscriptions(
            options: DeepLinkOptions(
              skuAndroid: purchase.productId,
              packageNameAndroid: 'com.example.app',
            ),
          ),
          child: Text('Fix Now'),
        ),
      ],
    ),
  );
});

Kotlin Multiplatform

kmpIapInstance.subscriptionBillingIssueListener
    .onEach { purchase ->
        kmpIapInstance.deepLinkToSubscriptions(
            DeepLinkOptions(
                skuAndroid = purchase.productId,
                packageNameAndroid = "com.example.app",
            ),
        )
    }
    .launchIn(scope)

Godot

godot_iap.subscription_billing_issue.connect(
    func(purchase: Dictionary) -> void:
        show_payment_issue_dialog(purchase["productId"])
)

The Recommended UX Pattern

The recommended user experience is intentionally simple.

When the event fires, do not immediately block the user. Instead, show a clear, non-intrusive message that explains the situation and gives them a direct way to fix it.

A good flow looks like this:

1. The billing issue event fires.
2. The app shows a non-blocking banner.
3. The banner says something like:
   “Your subscription needs attention.”
4. The user taps “Fix payment method.”
5. The app calls deepLinkToSubscriptions().
6. The platform opens the correct subscription management screen.
7. The user updates their payment method.
8. The subscription can recover on the next billing attempt.

Both OpenIAP example apps implement this exact pattern.

The subscription screen shows an orange warning banner with a dismiss button and a Fix payment method action.

Simple.

Visible.

Recoverable.

Why Client-Side Detection?

Server-to-server notifications are still the best solution for critical backend business logic.

You should still use server-side verification for entitlement enforcement, auditability, fraud protection, and subscription state reconciliation.

But for the user-facing moment — the moment where you simply want to say:

“Your payment method failed. Please update it before you lose access.”

Client-side detection has real advantages.

1. Zero Infrastructure

There is no webhook endpoint to host.

No backend route to secure.

No notification delivery system to maintain.

No server polling.

No queue.

No retry system.

For indie developers and small teams, this matters.

You can add a billing recovery flow directly inside the app without building an entire subscription backend first.

2. The User Sees It While They Are Active

Push notifications are easy to ignore.

Emails are easy to miss.

But if the user opens your app while the subscription is in a billing retry or suspended state, the app can show the message immediately.

That creates a much better recovery moment.

The user is already engaged.

They are already using the product.

They are much more likely to fix the issue right there.

3. It Works Without Your Server

The detection comes from the platform billing SDK.

That means the app can surface the warning without first making a network request to your backend.

This is especially useful for apps that are offline-first, lightweight, or still early in their infrastructure journey.

4. It Complements Server-Side Verification

This feature does not replace backend validation.

It is not intended to be the only source of truth for subscription access.

Instead, think of subscriptionBillingIssue as an early warning system.

Your backend may still be responsible for final entitlement decisions.

But the client can now help the user fix a payment problem before it turns into a cancellation.

Platform Support

PlatformSignalDeliveryDeduplicationiOS 18+ / Mac Catalyst 18+Message.Reason.billingIssuePush while app is activePer message, scans current entitlementsAndroid / Play Billing 8.1+Purchase.isSuspendedgetAvailablePurchases and onPurchasesUpdatedBy purchaseToken, once per sessionAndroid / Meta HorizonNot availableNever firesN/AiOS 17 and earlierNot availableSilent no-opN/AmacOS / tvOS / watchOS / visionOSMessage not availableSilent no-opN/A

On Android, listener collections use CopyOnWriteArraySet, and token deduplication uses ConcurrentHashMap.newKeySet().

This makes listener add/remove operations safe against iteration from background dispatchers.

Package Versions

This feature ships across the OpenIAP ecosystem:

PackageVersionopeniap-apple2.1.0openiap-google2.1.0react-native-iap15.2.0expo-iap4.1.0flutter_inapp_purchase9.2.0kmp-iap2.2.0godot-iap2.2.0

The Monorepo Advantage

This feature landed across the entire OpenIAP ecosystem in a single coordinated update:

• Schema update
• iOS implementation
• Android implementation
• Horizon no-op support
• React Native bridge
• Expo support
• Flutter bridge
• Kotlin Multiplatform bridge
• Godot bridge
• useIAP hook support
• Example app UI
• Documentation
• Robolectric test
• Sandbox E2E guide

That is exactly why we moved the OpenIAP framework libraries into one monorepo.

One spec.

One source of truth.

One feature, shipped across every supported framework.

Final Thoughts

Failed subscription payments are not always lost customers.

Sometimes they are just users who need a timely reminder.

With subscriptionBillingIssue, apps can now detect billing problems directly on the client and guide users to fix their payment method before access is lost.

It is not a replacement for server-side subscription infrastructure.

But it gives every developer — including indie developers and small teams — a practical recovery path that works directly inside the app.

And for subscription products, that small moment can make a big difference.

OpenIAP is the standardized protocol for in-app purchases.

Website: https://openiap.dev
Release notes: https://www.openiap.dev/docs/updates/releases#releases-2026-04-16

Detecting Failed Subscription Payments on the Client — No Backend Required was originally published in Hyo Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

In-app purchase libraries are uniquely painful to maintain across multiple repositories. A single type change in the core schema ripples into Swift, Kotlin, TypeScript, Dart, and GDScript — five PRs, five CI pipelines, five version bumps, and five chances for something to drift.

We maintained exactly this setup for years. Five separate repos, each with its own release cycle, its own copy of generated types, and its own set of contributors who had no visibility into what the other platforms were doing.

In April 2026, we merged everything into one monorepo. This is what we learned.

The Problem

OpenIAP defines a cross-platform specification for in-app purchases. The core packages — a GraphQL schema, an iOS library (StoreKit 2), and an Android library (Google Play Billing + Meta Horizon) — live in the `openiap` repo. Five framework SDKs consume them:

- react-native-iap — React Native via Nitro Modules
- expo-iap — Expo Modules
- flutter_inapp_purchase— Flutter method channels
- kmp-iap — Kotlin Multiplatform via cinterop
- godot-iap — Godot 4.x GDExtension + AAR plugin

Each SDK had its own GitHub repo, its own `openiap-versions.json` pinning core dependency versions, and its own CI that downloaded pre-built artifacts from GitHub Releases.

A typical schema change looked like this:

1. PR to openiap — update GraphQL, regenerate types, update Swift + Kotlin
2. Tag + release `openiap`
3. Open 5 PRs across 5 repos, each updating `openiap-versions.json` and syncing generated types
4. Wait for 5 CIs to pass
5. Merge and publish 5 packages (npm x 2, pub.dev, Maven Central, GitHub Release)

Steps 3–5 were where things broke. A field name would get corrected in one PR but not another. A Kotlin type would drift from the Dart equivalent. A release would ship with a stale dependency version because someone forgot to bump `openiap-versions.json`.

The Decision

We considered three options:

Option A: Git submodules. Each SDK repo adds `openiap` as a submodule. Types are always at the pinned commit. But submodules are hostile to contributors — `git clone — recurse-submodules` is a speed bump that filters out casual contributions, and CI caching with submodules is fragile.

Option B: Published package dependencies. Each SDK depends on published openiap-google / openiap-apple packages from Maven Central, CocoaPods, etc. This is what we already had, and it was the source of the drift problem. You can’t atomically ship a core change + all SDK updates.

Option C: Monorepo. Move all five SDK directories into `openiap/libraries/`. One PR touches core + all SDKs. One CI runs all checks. Version drift becomes a compile error, not a production bug.

We chose C.

The Migration

The actual move was mechanical:

openiap/
├── packages/ # Core (unchanged)
│ ├── apple/
│ ├── google/
│ ├── gql/
│ └── docs/
├── libraries/ # NEW — moved from separate repos
│ ├── react-native-iap/
│ ├── expo-iap/
│ ├── flutter_inapp_purchase/
│ ├── godot-iap/
│ └── kmp-iap/
└── libraries-versions.jsonc # “local” vs published toggle

The key design decision was `libraries-versions.jsonc`:

{
 “expo-iap”: “local”,
 “react-native-iap”: “local”,
 “flutter_inapp_purchase”: “local”,
 “kmp-iap”: “local”
}

When set to local, each library resolves its openiap dependency from the monorepo source. When set to a version string like 4.0.0-rc.1, it pulls the published package. This lets contributors develop against HEAD and release managers validate against published artifacts — same repo, same CI.

What Changed for Contributors

Before: Clone the SDK repo, clone openiap separately, set $IAP_REPOS_HOME and $OPENIAP_HOME environment variables, run a sync script.

After: Clone one repo. Everything compiles.

Before: A type change requires coordinating across repos with different maintainers and review cadences.

After: One PR. The type regeneration script (`bun run generate`) updates Types.swift, Types.kt, types.ts, types.dart, and types.gd in a single pass, and the sync script copies them to all five libraries. If any library doesn’t compile, the PR doesn’t merge.

What Changed for CI

Each library kept its own CI workflow (separate YAML files), but they all trigger on the same PR. A schema change in `packages/gql/` triggers:

- ci.yml — Apple `swift build && swift test`, Google `compilePlayDebugKotlin && compileHorizonDebugKotlin`, Docs typecheck
- ci-react-native-iap.yml — `yarn typecheck && yarn test`
- ci-expo-iap.yml — `bun run tsc — noEmit && bun run test`
- ci-flutter_inapp_purchase.yml — `flutter analyze && flutter test`
- ci-kmp-iap.yml — `gradlew :library:compileDebugKotlinAndroid`
- ci-godot-iap.yml — GDScript syntax check

If any fails, the PR is blocked. Version drift is now a CI failure, not a bug report.

What We’d Do Differently

Git history. We moved directories rather than using `git filter-repo` to transplant history. This means `git log libraries/react-native-iap/src/index.ts` starts at the consolidation commit, not at the file’s original creation. For a library with 10+ years of history like react-native-iap, that’s a real loss. If we did it again, we’d invest the time in proper history grafting.

Gradual migration. We moved all five at once. In retrospect, moving one library first (expo-iap, the smallest) as a proof-of-concept would have let us iron out CI and dependency resolution issues before committing to the full migration.

Results

In the weeks since consolidation:

- Zero type drift incidents (previously ~1 per release cycle)
- PR-to-all-platforms merge time dropped from 2–3 days to same-day
- New feature PRs (like `subscriptionBillingIssue`) ship core + all 5 SDK bridges + docs + example apps in a single PR
- Contributor onboarding simplified to one clone + one build command per platform

The monorepo isn’t magic. It’s a trade-off: you accept a larger repo, more complex CI triggers, and occasionally longer CI times in exchange for atomic cross-platform changes and zero coordination overhead. For a project whose entire value proposition is cross-platform consistency, that trade-off is clear.

• OpenIAP is the standardized protocol for in-app purchases across platforms. Learn more at openiap.dev.
• The consolidation discussion: https://github.com/hyodotdev/openiap/discussions/86

We Merged 5 IAP Libraries Into One Monorepo — Here’s Why and How was originally published in Hyo Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this article, I want to take a closer look at one of the most talked-about projects recently: Clawdbot — now reborn as Moltbot after a trademark complaint from Anthropic forced a name change.
As the name suggests, it has shed its old skin. But has it truly become stronger?

Right now, communities like X and Reddit are on fire over Moltbot. This AI runs 24/7, all year round. One viral post claimed that a user entrusted the bot with $1 million in capital to manage. The bot reportedly analyzed over 3,000 reports in real time, charted every technical indicator, and executed stock trades nonstop.

The result?
All the money was lost — but, as the post jokingly put it, “the process was beautiful.”

At this very moment, people are posting screenshots of Moltbot automatically sending affectionate messages to their girlfriends, writing complex code, or trading stocks on their behalf. Yet the developer has been clear: this started as a personal hobby project, meant to inspire people — not a magic tool to make them rich.

Despite that, many have misunderstood it as a shortcut to becoming a millionaire. Some even claim there’s a Mac mini shortage because people are buying them in bulk just to run Moltbot 24/7.

So what exactly is this thing? And why are people reacting this way?

Let’s break it down — and then look at it honestly from a developer’s perspective.

Installation & Setup (Quick Notes)

Since many readers have already heard about Moltbot, I’ll keep this short.

One small tip: I initially tried installing it via npm, but ran into a missing CLI error. Reinstalling via curl worked without issues.

During setup, you’re greeted with a rather alarming warning: the bot can control your file system. This is not something to click through lightly. Read it carefully before proceeding.

You then enter onboarding, where you choose a model. Instead of entering an API key (and risking surprise billing later), I opted for Google OAuth, since I already subscribe to Gemini. I selected Gemini 2.5 Pro for better performance.

You’re asked about channels, skills, hooks, gateways, and execution environments. Many of these involve fairly powerful permissions. I skipped most of them for now and chose to run the bot in the terminal UI, which the project itself recommends.

Once launched, a browser window opens alongside the terminal. The bot asks for your name — and from there, you can literally watch it store and remember information about you in real time.

That’s enough for the walkthrough. Now let’s talk about what actually matters.

1. The Real Innovation: Not Technology, but Positioning

Moltbot’s GitHub stars are skyrocketing, and there’s a reason.
But if we strip things down to their technical essence, Moltbot is not fundamentally new technology.

Calling LLMs, storing state, connecting external tools — all of this can already be done with Claude Skills, ChatGPT Actions, LangChain, or Zapier. Even the so-called “gateway” is, in practice, just a long-running bot with webhooks and a scheduler.

So why are people so impressed?

Because the innovation isn’t how it works — it’s where it lives.

Traditional AI tools like ChatGPT require you to open an app and initiate work. You are always in control. Moltbot, on the other hand, lives inside your messenger — WhatsApp, Telegram, the same place you already spend your day. It’s always on. Always present.

If ChatGPT suddenly started messaging you first, it would feel like spam.
But Moltbot feels like a personal assistant.

The technology is similar. The UX and power dynamics are not.

Who controls the conversation?
Who is always running?

This shift — the idea of an AI agent that lives where you live — is the first reason people are excited.

The One Genuine Technical Differentiator: Disk-Based Memory

There is, however, one truly meaningful technical distinction.

Moltbot uses the local hard disk as long-term memory.

Most cloud AIs eventually forget earlier context as conversations grow longer. Moltbot stores conversations and state as files and reloads them later. As long as your disk has space, memory is effectively unlimited.

This disk-backed, persistent memory model is genuinely hard for traditional cloud services to replicate — and it is Moltbot’s strongest technical advantage.

2. Model Limitations and the Refactoring Hell Problem

Despite its innovative positioning, there are serious concerns from a professional developer’s perspective.

Memory Is Not Truth

Many people assume that because the bot “remembers,” it will automatically improve over time. That’s a dangerous misunderstanding.

Without a Single Source of Truth, persistent memory simply preserves mistakes along with correct information.
If your system doesn’t have a top-level constitution — immutable rules that override everything else — the AI will faithfully repeat bad assumptions forever.

Right now, Moltbot lacks this.

The Inability to Stop

This is the most critical issue.

Agents like Moltbot suffer from the same fundamental problem that plagued Auto-GPT: once they start down a wrong path, they don’t know when to stop.

Humans feel uncertainty. When something feels off, we pause, reconsider, or ask for help. Current LLM-based agents don’t. If the initial assumption is wrong, they keep building on it, refactoring again and again — until the entire project collapses into a mess.

This isn’t a Moltbot-specific design flaw. It’s a limitation of today’s models.
They lack robust uncertainty detection and the ability to say, “I’m not sure — I need human input.”

The result is what many developers have experienced firsthand: refactoring hell.

In short, Moltbot is an excellent proposal for where AI should live — but the underlying model maturity isn’t there yet for it to be a primary development tool. For now, it should be treated as a powerful experimental platform, not production infrastructure.

3. About the Mac Mini Frenzy

Finally, let’s talk hardware.

The model limitations I mentioned will improve over time. And when they do, we’ll move away from cloud APIs toward local, always-on intelligence. That’s the future Moltbot hints at.

For that reason, I don’t recommend buying a base-model Mac mini just to run Moltbot today.

But if your goal is to someday run Gemini-2.5-Pro-level intelligence locally, without worrying about usage fees, that’s a different story.

In that future, the most important spec won’t be CPU speed.

It will be memory.

I strongly believe that machines with at least 64GB of RAM will become the foundation of personal AI infrastructure. Prepare for that future, and you’ll be ready when the models finally catch up.

Thanks for reading.
If you have thoughts or questions, I’d love to continue the discussion in the comments.