DEV Community: Steve Dornan

Stripe Web Checkout in a Mobile App: The Post-Epic External Payments Pattern (.NET Implementation)

Steve Dornan — Wed, 05 Aug 2026 13:53:02 +0000

Part of a short series on shipping subscriptions in .NET MAUI — see also the full RevenueCat setup guide and the AMM0000 build-error fix.

Since the Epic v. Apple injunction took effect, US App Store apps can link out to external purchase flows — and keep the store's 15–30% cut. Google has its own external-offers programs. Every subscription-app developer is now asking the same question: how do I actually build the web-payment path without getting rejected or double-charging users?

Here's the architecture that works, with a concrete ASP.NET Core + .NET MAUI implementation. The pattern is identical in any stack.

The architecture in one diagram

┌─ App ─────────────┐        ┌─ Your API ────────────┐        ┌─ Stripe ─────────┐
│ Paywall           │        │                       │        │                  │
│  "Subscribe on    │──1──→  │ POST /billing/        │──2──→  │ Checkout Session │
│   the web $9.99"  │        │      checkout-link    │        │ (hosted page)    │
│                   │ ←──3── │   returns session URL │        │                  │
│ opens SYSTEM      │        │                       │        │ user pays here   │
│ browser ──────────┼────────┼───────────────────────┼──4──→  │                  │
│                   │        │ POST /billing/webhook │ ←──5── │ checkout.session.│
│ "I paid → refresh"│──6──→  │ grants entitlement    │        │   completed      │
└───────────────────┘        └───────────────────────┘        └──────────────────┘

Three rules make this compliant and reliable:

System browser, not a WebView. The external-link model both stores permit means leaving the app. A WebView checkout is how you fail review.
Entitlement is granted server-side by webhook — never by the client claiming "I paid." This also means a purchase made on your website, with no app involved, unlocks the app. (That "Reader-style" flow has always been allowed.)
The app discovers the entitlement by asking your server, merged with any store subscription so your feature gates don't care where the money came from.

Server: creating the checkout link

The critical detail is ClientReferenceId — it ties the anonymous Stripe session back to your authenticated user when the webhook fires:

var session = await new SessionService().CreateAsync(new SessionCreateOptions
{
    Mode = "subscription",
    LineItems = [ new() { Price = priceId, Quantity = 1 } ],
    ClientReferenceId = userId.ToString(),          // ← the linchpin
    SuccessUrl = _options.CheckoutSuccessUrl,
    CancelUrl  = _options.CheckoutCancelUrl,
    SubscriptionData = new SessionSubscriptionDataOptions
    {
        Metadata = new() { ["userId"] = userId.ToString(), ["tier"] = tierId }
    }
});
return session.Url;   // app opens this in the system browser

Putting userId in the subscription's metadata too means renewal and cancellation webhooks — which arrive months later with no session context — can still find your user.

Server: the webhook

[HttpPost("webhook")]
public async Task<IActionResult> Webhook()
{
    var json = await new StreamReader(Request.Body).ReadToEndAsync();
    var stripeEvent = EventUtility.ConstructEvent(
        json, Request.Headers["Stripe-Signature"], _webhookSecret);  // verify!

    switch (stripeEvent.Type)
    {
        case "checkout.session.completed":      // initial purchase
        case "customer.subscription.updated":   // renewals, plan changes
        case "customer.subscription.deleted":   // cancellations
            await _billing.HandleAsync(stripeEvent);
            break;
    }
    return Ok();
}

One Stripe-API gotcha that costs people an hour: in current API versions, current_period_end lives on the subscription item, not the subscription:

var periodEnd = stripeSub.Items?.Data?.FirstOrDefault()?.CurrentPeriodEnd;

Client: merged entitlement state

The app's subscription service checks the store SDK first, then your API:

public async Task<SubscriptionState> GetStateAsync(bool forceRefresh = false)
{
    // 1. Store entitlement (RevenueCat / StoreKit / Play Billing)
    if (storeEntitlementActive) return storeState;

    // 2. Web/trial subscription from your API
    var web = await _billingApi.GetStatusAsync();   // JWT-authenticated
    if (web?.HasActiveSubscription == true)
        return new SubscriptionState { IsPremium = true, Source = "web", ... };

    return SubscriptionState.None;
}

And because the user returns from the browser with no signal, give them a refresh affordance on the paywall: "I completed my purchase — refresh." One tap, GetStateAsync(forceRefresh: true), entitlement appears.

The policy question everyone asks

"Will Apple/Google reject this?" The honest answer: rules differ by market and have changed more than once. Two design decisions de-risk it:

Serve the web tiers from your API. If a market doesn't permit external links, return an empty array there — the UI section never renders, no app update needed.
Web purchases work without the app ever linking out. Worst case, you market the web plan on your website and the app just honors it. That path has always been allowed.

Local testing

stripe listen --forward-to http://localhost:5199/api/billing/webhook
stripe trigger checkout.session.completed

This entire flow — plus RevenueCat store billing, OTP auth with rotating refresh tokens, server-issued trials, and a finished paywall — ships wired-and-compiling in *MidasKit*, the .NET MAUI subscription-app boilerplate. Skip the integration month.

Fix: AMM0000 "Namespace used in multiple modules" When Adding Google Play Billing to .NET MAUI

Steve Dornan — Fri, 24 Jul 2026 13:01:17 +0000

Setting up subscriptions from scratch? Start with the full .NET MAUI + RevenueCat setup guide — then come back here the moment the build breaks with AMM0000.

You added an in-app billing package to your .NET MAUI app (RevenueCat wrapper, Plugin.InAppBilling, or anything pulling Google Play Billing), hit build, and got a wall of this:

java.exe error AMM0000: ...\AndroidManifest.xml Warning:
    Namespace 'com.android.billingclient' is used in multiple modules and/or libraries:
    AndroidManifest.xml, AndroidManifest.xml. Please ensure that all modules and
    libraries have a unique namespace.
java.exe error AMM0000:     Namespace 'com.google.android.gms.base' is used in multiple modules...
java.exe error AMM0000:     Namespace 'com.google.firebase.encoders.json' is used in multiple modules...
Build FAILED.

Dozens of repeated "namespace" errors pointing at billing.aar, play-services-base.aar, and friends. Cleaning bin/obj doesn't help. Downgrading packages doesn't help.

The trap

Those namespace lines are not your problem. They're warnings from the Android manifest merger that .NET for Android surfaces with an error AMM0000 prefix, which makes everyone chase the wrong thing (I did too).

Scroll to the bottom of the error output. The actual build-killer is almost always this:

uses-sdk:minSdkVersion 21 cannot be smaller than version 23 declared in library
[...androidx.lifecycle...]
    Suggestion: use a compatible library with a minSdk of at most 21,
        or increase this project's minSdk version to at least 23

The .NET MAUI project template sets Android minimum to API 21. The Play Billing dependency chain (via androidx.lifecycle and GMS libraries) requires API 23+. The merger fails on that one real error — and dumps every accumulated warning alongside it, burying the signal.

The fix (one line)

In your .csproj, raise the Android minimum:

<SupportedOSPlatformVersion
    Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'android'">
    24.0
</SupportedOSPlatformVersion>

Rebuild. The minSdk error is gone, the namespace warnings stop being fatal, and the build passes:

Build succeeded.
    0 Error(s)

Why 24 and not 23?

23 satisfies today's constraint; 24 clears the next library in the chain that wants it and still covers ~97%+ of active Android devices. If your analytics say you need 23, use 23 — the point is anything ≥ the version named in your error message.

Things that do NOT fix it (save yourself the afternoon)

❌ Cleaning bin and obj
❌ <AndroidManifestMerger>legacy</AndroidManifestMerger> — the warnings persist and you lose modern merger features
❌ tools:overrideLibrary — works around the symptom, invites runtime crashes on old devices
❌ Downgrading the billing package — the androidx floor moved ecosystem-wide

The pattern to remember

When .NET for Android gives you a wall of AMM0000 output: ignore every line that says Warning: and read the last block. The merger reports exactly one fatal condition; everything else is decoration.

This is one of a dozen integration landmines I defused while building *MidasKit** — a .NET MAUI subscription-app boilerplate with RevenueCat, Stripe web checkout, auth, and a finished paywall already wired and compiling. If you're adding billing to a MAUI app right now, it'll save you the rest of the week.*

.NET MAUI In-App Subscriptions with RevenueCat: The 2026 Setup That Actually Compiles

Steve Dornan — Thu, 23 Jul 2026 14:45:48 +0000

If you've searched "RevenueCat MAUI" you've already discovered the awkward truth: RevenueCat has no official .NET MAUI SDK. Flutter, React Native, Unity, Cordova, KMP — all officially supported. MAUI? A community wrapper and a forum thread from 2023 asking when it's coming.

Here's the good news: the community answer is actually solid, and in this guide we'll go from File > New Project to a working subscription purchase on Android — including the two build errors that stop most people, and how to structure the code so your app never depends on any particular billing SDK.

The lay of the land

Your realistic options for MAUI subscriptions in 2026:

Option	Verdict
Plugin.InAppBilling	Direct store billing. Works, but you get raw store APIs — receipt validation, cross-platform entitlement logic, and grace-period handling are all yours to build.
Kebechet.Maui.RevenueCat.InAppBilling	Community wrapper around RevenueCat's native SDKs. Actively maintained (v7.x, updated mid-2026), unified C# API, and you inherit RevenueCat's server-side receipt validation, entitlements, and analytics.
Raw StoreKit 2 / Play Billing bindings	You are now a billing infrastructure company.

We're using the Kebechet wrapper. RevenueCat's free tier covers you to $2,500/month tracked revenue, which is exactly the phase where you shouldn't be building billing infrastructure.

Step 1 — Install

dotnet add package Kebechet.Maui.RevenueCat.InAppBilling

Step 2 — The two build errors everyone hits

Error 1: AMM0000 manifest merger failure. The moment you add the package, your Android build explodes with walls of "Namespace 'com.android.billingclient' is used in multiple modules" warnings and, buried at the bottom, the actual killer:

uses-sdk:minSdkVersion 21 cannot be smaller than version 23
declared in library [androidx.lifecycle...]

The MAUI template defaults to Android API 21. The Play Billing dependency chain requires more. The fix is one line in your .csproj:

<SupportedOSPlatformVersion
    Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'android'">
    24.0
</SupportedOSPlatformVersion>

(24 rather than 23 keeps you clear of the whole chain and covers 97%+ of active devices.) The namespace warnings are noise — once the minSdk error is gone, the build passes. I wrote a separate deep-dive on this exact error.

Error 2: IHttpClientFactory not found — not from this package, but you'll hit it the moment you wire your paywall to a backend. dotnet add package Microsoft.Extensions.Http.

Step 3 — Initialize (in the right place)

The SDK must initialize in OnStart, not in App's constructor:

public partial class App : Application
{
    private readonly ISubscriptionService _subscriptions;

    public App(ISubscriptionService subscriptions)
    {
        InitializeComponent();
        _subscriptions = subscriptions;
    }

    protected override void OnStart()
    {
        _subscriptions.Initialize();   // wraps Purchases.Configure
        base.OnStart();
    }
}

Notice we're already hiding RevenueCat behind our own interface. That's the single most important decision in this article — more below.

Step 4 — Don't marry the SDK: the `ISubscriptionService` abstraction

The wrapper's IRevenueCatBilling interface is fine, but binding your ViewModels to it means every SDK change ripples through your app. Define the interface your app actually needs:

public interface ISubscriptionService
{
    void Initialize();
    Task LoginAsync(Guid userId);
    Task LogoutAsync();
    Task<SubscriptionState> GetStateAsync(bool forceRefresh = false);
    Task<bool> IsPremiumAsync();
    Task<IReadOnlyList<StorePackage>> GetPackagesAsync(bool forceRefresh = false);
    Task<PurchaseResult> PurchaseAsync(StorePackage package);
    Task<bool> RestoreAsync();
}

Then the RevenueCat-backed implementation maps their DTOs to yours:

public async Task<IReadOnlyList<StorePackage>> GetPackagesAsync(bool forceRefresh = false)
{
    var offerings = await _revenueCat.GetOfferings(forceRefresh);
    return offerings
        .SelectMany(o => o.AvailablePackages)
        .Select(p => new StorePackage
        {
            Identifier = p.Identifier,
            Title = p.Product.Sku,
            PriceLocalized = p.Product.Pricing.PriceLocalized,
            Period = p.Product.SubscriptionPeriod?.Unit.ToString(),
            NativePackage = p            // opaque handle for purchase time
        })
        .ToList();
}

Two huge wins fall out of this:

A mock implementation for Windows. MAUI development on Windows is fast — but there's no Play Store on your dev box. Register a MockSubscriptionService for non-mobile targets and you can build and demo your entire paywall flow without an emulator or a store account:

#if ANDROID || IOS
    builder.Services.AddRevenueCatBilling();
    builder.Services.AddSingleton<ISubscriptionService, RevenueCatSubscriptionService>();
#else
    builder.Services.AddSingleton<ISubscriptionService, MockSubscriptionService>();
#endif

Web payments slot in invisibly. When you later add Stripe checkout for web purchases (post-Epic external links), GetStateAsync() merges both sources and your feature gates never change.

Step 5 — Identify the user

Anonymous purchases are a support nightmare — the moment a user reinstalls or switches devices, "where's my subscription?" tickets begin. After your login flow succeeds:

await _subscriptions.LoginAsync(userId);   // RevenueCat Login(appUserId)

Now entitlements follow the account, not the device.

Step 6 — Gate features

[RelayCommand]
private async Task UsePremiumFeatureAsync()
{
    if (!await _subscriptions.IsPremiumAsync())
    {
        await _nav.GoToPaywallAsync();
        return;
    }
    // premium feature
}

GetStateAsync checks the RevenueCat entitlement (cached ~5 min) and falls back to your server for web/trial subscriptions. One code path, every payment source.

Step 7 — RevenueCat dashboard wiring

Project → Android app (package name) + iOS app (bundle id) → copy the public API keys.
Create the store products (Play Console / App Store Connect).
RevenueCat: create an entitlement (premium), attach products, build the default offering.

The offering is why this beats hardcoding SKUs: your paywall renders whatever the offering contains, so you can test pricing without shipping an app update.

Testing on Android

Upload one build to a Closed Testing track, add yourself as a license tester, and purchases on debug builds use test cards. No real money, real purchase flow.

Or skip all of it

Everything in this article — plus the auth system (OTP, JWT, rotating refresh tokens), the Stripe web-checkout path, server-issued free trials, and a finished paywall UI — is packaged as MidasKit, a production-grade .NET MAUI subscription boilerplate. It compiles out of the box; you wire your keys and ship. Get it here.