In-App Billing Plugin for .NET MAUI and Windows

Consumables are items that can be purchased multiple times (e.g., virtual currency). Because they are reusable, you are responsible for managing their lifecycle: verifying the purchase, providing the item to the user, and consuming the purchase to allow for subsequent buys.

Platform Differences

• Apple (iOS): Referred to as Consumable. You must manually consume the purchase to finish the transaction (starting in versions 5.x and 6.x, auto-consumption is not the default behavior).
• Android: Referred to as Managed Product. You must consume the purchase before the user can purchase the same item again; this also acts as an acknowledgment of the transaction.
• Microsoft (Windows): Referred to as Developer-managed consumable. You must consume the purchase before the user can purchase it again.

Lifecycle Requirements

1. Always call ConnectAsync() before initiating a purchase.
2. Always call DisconnectAsync() when finished with billing operations.
3. For all platforms, use PurchaseAsync to initiate the transaction.
4. For all platforms (with specific configuration for iOS), use ConsumePurchaseAsync to finalize the transaction and enable repeat purchases.

// High-level flow
await billing.ConnectAsync();
var purchase = await billing.PurchaseAsync(productId, ItemType.InAppPurchaseConsumable);
if (purchase?.State == PurchaseState.Purchased)
{
    // Process item delivery
    await billing.ConsumePurchaseAsync(purchase.ProductId, purchase.TransactionIdentifier);
}
await billing.DisconnectAsync();

The plugin implements IDisposable to ensure that platform-specific events (such as the SKPaymentQueue on iOS) are properly unregistered.

Important: While you can use a using statement on the Current instance, the recommended pattern is to call CrossInAppBilling.Dispose() on the static class itself. Calling CrossInAppBilling.Dispose() handles the disposal of the Current instance. The next time you access CrossInAppBilling.Current, a new instance will be created.

Avoid disposing of the instance manually if you still need to listen to events; only dispose when you are finished with the billing lifecycle.

public async Task<bool> MakePurchase()
{
    if(!CrossInAppBilling.IsSupported)
        return false;

    var billing = CrossInAppBilling.Current;
    
    try
    {
        var connected = await billing.ConnectAsync(ItemType.InAppPurchase);
        if(!connected)
            return false;
        
        // make additional billing calls
    }
    finally
    {
        await billing.DisconnectAsync();
    }

    // This is the recommended way to dispose of the plugin and its current instance
    CrossInAppBilling.Dispose();
}

In-app billing operations are complex and prone to failure. This library abstracts various billing errors into a single InAppBillingPurchaseException. This exception can be thrown by most API calls, except for DisconnectAsync, which is designed not to throw.

When catching an InAppBillingPurchaseException, you can access:

1. A message returned from the billing server.
2. A PurchaseError enum value to programmatically determine the cause of the failure and show appropriate feedback to the user.

var billing = CrossInAppBilling.Current;
try
{
    var connected = await billing.ConnectAsync(ItemType.InAppPurchase);
    if (!connected) return;

    var purchase = await billing.PurchaseAsync(productId, ItemType.InAppPurchase);
    if(purchase == null) { /* did not purchase */ }
    else { /* purchased! */ }
}
catch (InAppBillingPurchaseException purchaseEx)
{
    // Use purchaseEx.PurchaseError to handle specific error cases
    switch (purchaseEx.PurchaseError)
    {
        case PurchaseError.AppStoreUnavailable:
            // Handle app store unavailable
            break;
        // ... other cases
    }
}
catch (Exception ex)
{
    // Handle non-billing related exceptions
}
finally
{
    await billing.DisconnectAsync();
}

If you are enabling "promoted items" (allowing users to purchase directly from the App Store), you must handle the OnShouldAddStorePayment event.

In .NET MAUI, you can implement this within your MauiProgram.cs using ConfigureLifecycleEvents to hook into the iOS FinishedLaunching event.

using Microsoft.Extensions.Logging;
using Microsoft.Maui.LifecycleEvents;
#if IOS
using StoreKit;
#endif

namespace MauiApp4;

public static class MauiProgram
{
    public static MauiApp CreateMauiApp()
    {
        var builder = MauiApp.CreateBuilder();
        builder
            .UseMauiApp<App>()
            .ConfigureLifecycleEvents(AppLifecycle =>
             {
#if IOS
                 AppLifecycle.AddiOS(ios =>
                     ios.FinishedLaunching((del, b) =>
                    {
                        Plugin.InAppBilling.InAppBillingImplementation.OnShouldAddStorePayment = OnShouldAddStorePayment;
                        var current = Plugin.InAppBilling.CrossInAppBilling.Current;
                        return true;
                    }));
#endif
             });

#if IOS
        bool OnShouldAddStorePayment(SKPaymentQueue queue, SKPayment payment, SKProduct product)
        {
            //Process and check purchases
            return true;
        }
#endif

        return builder.Build();
    }
}