InAppBilling

[dhindrik]

@jamesmontemagno had a project/plugin for InAppBilling, https://github.com/jamesmontemagno/InAppBillingPlugin, which he has now archived. I think that is a really important part for the .NET MAUI Community. The best would be official support for a project like that. But I guess we never will get that. But when I discussed it with my friend and colleague @EngstromJimmy, he said something good, "that should be part of Community Toolkit". And I agree with that! What do you think?

[ghost]

While waiting, you can check following resources:

1. Somebody wrote some code for listeners - Android only
2. Maui In-AppBilling advice under Q&A
3. Stackoverflow - How to set up google play console subscriptions in Maui app
4. Reddit - I need to manage native in app subscriptions
5. Sample Payment App with Prism.MAUI

[jfversluis]

Allow me to answer this in a bit more detail than you probably anticipated, but I just want to bring a little clarity into why we won't just say yes to doing this, but I also don't want you to be disappointed if we say no and you don't understand why 😄

While I always welcome a great idea for the Toolkit (and you know me, I like to say "yes" a lot...) I do think we also need to realize that this project is still ran by community members. There is a group of core maintainers that stuck around over the years, but other also have come and gone. Which is a good thing, a healthy thing and I'm grateful for each and everyone of those people, but the core maintainers group is and has always been a handful of people. And since its "just" community work, next to our daily jobs and lives, we will sometimes have more time and sometimes have less time to spend on a project like this.

So, while great ideas are always coming in for features big and small (and I definitely think this is a bigger one), its hard, if not impossible, for us to take in everything. A one-time contribution is relatively easy to make, but what comes after that makes it hard. That code needs to be maintained. What happens a lot of the time is that someone will come in, contribute something amazing and then move on to the next thing. Which is totally fair: thank you for the great work and all the best! But that now presents us (the core maintainers) with a problem: we have a feature that none of us really know much about, that is slowly rotting, using older APIs, people want more features etc. but we took it, so now its on us to maintain at the very least. While there is already a big codebase that we try to maintain. The more features we pick up, without the people sticking around to maintain it, the bigger the problem will get until we all get overworked and now the whole project will be at risk.

That brings me to: if we were to take something like this into the Toolkit, I think we would want to have some sense of commitment from someone that it will not only be contributed, but that person is also willing to own that piece and keep moving it forward. There is no formal contract or anything, but it would be good that this person would at least realize all of the above and would be willing and able to dedicate some time to help us out with this (or any other feature for that matter).

The community is all of us bringing value to the broader ecosystem, and this is a great way to pay it forward from all the work we might have saved you by just pulling in the Toolkit!

Also see: https://github.com/CommunityToolkit/Maui?tab=readme-ov-file#submitting-a-new-feature

Hope that helps! And... This is in no way an answer on if we would want to do this yes or now 🤪 but my initial reaction is: no, unless someone comes along to indeed own this piece of the Toolkit.

[nodoid]

If someone (say me) wanted to own this part, what would I need to do to own this?

[dhindrik]

I am also open to be an owner of this. But I need to to investigate a bit more how to do it in the best way.

I have done some investigation already and StoreKit2 is a big concern. There are no official MAUI support for that for the moment. There are third-party bindings. But I don't know if we want to use them in a project like this. Or maybe the bindings should be part of this project as will in that case. At least I need to read a bit more about Swift bindings before commiting to adding it to this project.

dotnet/macios#16893

[dhindrik]

Seems like we will have experimental support for swift bindings in .NET 10. dotnet/runtime#95633

[pictos]

It shouldn't be a blocker, it's possible to use the actual tech to binding swift API into maui.

My question is, what are the requirements to test this feature in each platforms? Can you please summarize it?

[dhindrik]

I think @jfversluis is a better person to answer the question.

[dhindrik]

Montemagnos recommendation is to not put it in the toolkit, https://x.com/JamesMontemagno/status/1940443476795232470

[jamesmontemagno]

I would highly recommend against putting this into the toolkit.

1. IAB is EXTREMELY complex
2. Needs constant updates with a bunch of dependencies
3. iOS needs new Swift only APIs which will make this difficult
4. Android is ever changing
5. There is no really good way to streamline the differences between the platforms
6. You are dealing with people money and that has a high level of stress and complexity

I would maybe say it is okay to fork it or start from scratch (probably better) and use all of the new Swift APIs and latest Android libraries, however maybe as a "reference" for how to use the binding libraries and something that is not supported officially. I would love for it to exist somewhere even if people pull the repo into their codebase as a submodule, but it is really complicated.

I have loved working on IAB but dealing and handling people money is another level and has always been high stress for me.

[ghost]

@jamesmontemagno that means that if somebody will fork your package and update, OK, otherwise RevenutCat is the only way to go in MAUI world for now?

I saw your last commit, this means is just a temporal fix until next APIs updates?

[dhindrik]

You can also include the code directly into your project. James' project is just an abstraction, so you can access the underlying APIs from shared code. Because it is a library, it is probably written with a general mindset. If you implement it yourself, you can write it more specifically to your needs.

[sonofsmog]

It’s complex, but it’s not that complex — definitely within reach of a solo dev using Claude/ChatGPT/Gemini. For example, I swapped out the old Windows.ApplicationModel.Store namespace to the newer Windows.Services.Store and added subscriptions across all three stores. Works well in production ($$).

The biggest burden isn’t the code, it’s navigating the labyrinth of requirements for each platform’s In-App Purchase, and then keeping docs up to date. Honestly, I’d just let AI help with the doc refresh.

Because of that, I’m not sure it’s a good fit for the Community Toolkit. It feels more like a standalone library (where I’d happily contribute or even publish my fork). The Toolkit might get bogged down in the store-specific policy churn.

[ghost]

@sonofsmog I think sharging your fork is always good as I can see there is a need for this. Maybe add some of your consulting option on top of that ($$).

[blmiles]

@sonofsmog - I'm very curious as to what changes you made to the InAppPlugin since I have a major blocker completing IAP in the MS Store. All works well in Android and iOS but just stops when connected to the MS Store - no errors returned, nothing in analytics.

This method does not retrieve the product data from the MS Store, yet it works in the others.
billing.GetProductInfoAsync(ItemType.InAppPurchase, prodIds);
Error msg: "Sequence contains no elements"

If I trigger a purchase with hardcoded values testing in Windows var purchase = await billing.PurchaseAsync(productId, ItemType.InAppPurchase);
The purchase popup appears, the store item flashes and disappears and I get the message - see image below...

Nothing special in code, standard implementation and both iOS and Android apps work fine.
The purchase item productId is the same across all stores too and no errors/issues cited in the MS Store either.

Anyone else have any insight into this?

Apart from that, this InAppBilling lib will need updating soon since SO MANY rely on it. I'm ok to work on it and provide feedback once I solve this current windows store issue as a priority. I have also tried using the InAppBillingPluginExtended but same errors/issues.

[borrmann]

Reading this thread leaves me worried.
The lack of monetization and analytics SDKs and generally SDKs built for and around monetization has probably been our biggest issue in our journey with MAUI. It meant a lot of work, because we tried to work around things by using unstable, undocumented or unmaintained projects which then also needed to be replaced after some time or alternatively we implemented things ourselves.
Of course, nothing can be taken for granted and I appreciate the work and all the unpaid hours by every community or single developer such as @jamesmontemagno and this toolkit - it helped us a lot and without this MAUI probably wouldn't have worked for us at all.

However, we are quite desperately looking for a better alternative, because the lack of support by tools like RevenueCat is a major disadvantage for the MAUI framework compared to what else is out there. This means any team that is using MAUI can't offer IAPs or has to put in more work to get them running and maintained. And as @jamesmontemagno mentioned, this is quite complex and therefore quite expensive. It has been shown that some vendors eventually do add MAUI, like Sentry or Branch.

Additionally, I am sure there are companies that would be willing to support an effort to solve this financially. We are still pretty small and couldn't contribute significant sums on the scales of a company like RevenueCat, but we would definitely try to help. We would also agree to pay a higher percentage than usual to a vendor.

Now, if I am suggesting this here, this probably won't get very far at all - but if the MAUI team or someone with reach within the community would somehow be able to collect some data from MAUI users around this topic and present it to such vendors (if there is a business case), maybe there would be a chance to get one of them over the line? If not RevenueCat, maybe one of the smaller ones who would gain a USP?
In the end this would benefit MAUI itself: the more successful, revenue-generating apps there are, the more vendor support follows (Syncfusion appears to be a great example).

@jfversluis Does this make sense, and could it be brought up with a MAUI PM?
I would definitely be willing to send a testimonial from our experience or agree up front to sign with a vendor / contribute up front if this would be of any help.

[jfversluis]

However, we are quite desperately looking for a better alternative, because the lack of support by tools like RevenueCat is a major disadvantage for the MAUI framework compared to what else is out there.

I think there is support for it? Right here: https://github.com/Redth/Plugin.RevenueCat

And we got a sample for implementing IAP for Android now right here: https://learn.microsoft.com/samples/dotnet/maui-samples/android-billing-service/

I don't think there is a lack of support for anything. MAUI apps are just native apps, most, if not all, APIs are available for you to use. A plugin or library is just work that someone else has done for you. Removing that dependency leaves you with more control and less risk for when someone stops maintaining it. However, that does not mean that it's impossible to implement IAP (or any other feature) in your MAUI app.

I forwarded your message to a PM, but honestly I don't think it will change much. I totally understand where you are coming from and that this is the most important thing for you, however for another person another thing might be most important and for a third person another thing, etc. The mobile ecosystem is so big, we just can't cover it all unfortunately. And as you mentioned: a lot of it are all unpaid hours by the community, you're more than welcome to become one of them if you think this is something you think that should be available for other people. I'm sure there will be a lot of people very thankful which is a great feeling and it works wonders for your resume!

But if not, I hope the above links will help you further!

[borrmann]

Thanks a lot for the links and for forwarding my message 🙏

[Flavio1997]

@jfversluis The sample link doesn't work anymore

[ghost]

@Flavio1997 does this help?

[jfversluis]

Ah because we added iOS we changed a value and that changes the URL. Sorry about that, new one is here: https://learn.microsoft.com/samples/dotnet/maui-samples/cross-platform-billing-service/ or indeed what @rokmeglic71 linked :)

[TheCodeTraveler]

We recommend using IAPHUB

https://github.com/iaphub/iaphub-dotnet

[sonofsmog]

@blmiles - Sorry, just saw this thread! Your issue is the deprecated API. The original plugin uses `Windows.ApplicationModel.Store` (`CurrentApp`/`CurrentAppSimulator`) which Microsoft deprecated in 2016. It doesn't work reliably with modern Store configurations, especially subscriptions. The fact that you're seeing the Store popup flash and disappear means the UI is trying to load - but the deprecated API can't properly communicate with the Store backend anymore for certain product types. ### The Fix The Windows implementation needs to be rewritten using `Windows.Services.Store` (`StoreContext`) instead. That's what I did for my app - full rewrite. Key differences: - `CurrentApp.LoadListingInformationAsync()` → `StoreContext.GetAssociatedStoreProductsAsync()` - `CurrentApp.RequestProductPurchaseAsync()` → `StoreContext.RequestPurchaseAsync()` - Also requires window handle initialization for Desktop Bridge apps (MAUI/WinUI) ### My Fork I'll clean up and post my fork this weekend. Beyond the Windows rewrite, we also added: **Windows:** - ✅ Modern `Windows.Services.Store` API - ✅ Working subscriptions (original throws `NotImplementedException`!) - ✅ Desktop Bridge support (MAUI/WinUI) - ✅ Dynamic product discovery - ✅ All the extras from StoreContext - recurrence pricing, sale info, user collection status, etc. **iOS/Mac:** - ✅ Enhanced receipt data - ✅ Additional StoreKit goodies **Android:** - ✅ Updated to pull more data from the billing API Basically we surface everything the stores give you, not just the basics. I'm happy to host it and keep it updated. Won't be a NuGet package initially, but working code on GitHub you can pull into your project. Will drop the link here when it's ready.

…

________________________________ From: Lindsay Miles ***@***.***> Sent: Wednesday, December 3, 2025 5:11 PM To: CommunityToolkit/Maui ***@***.***> Cc: Ontario Analytics ***@***.***>; Mention ***@***.***> Subject: Re: [CommunityToolkit/Maui] InAppBilling (Discussion #2783) @sonofsmog<https://github.com/sonofsmog> - I'm very curious as to what changes you made to the InAppPlugin since I have a major blocker completing IAP in the MS Store. All works well in Android and iOS but just stops when connected to the MS Store - no errors returned, nothing in analytics. This method does not retrieve the product data from the MS Store, yet it works in the others. billing.GetProductInfoAsync(ItemType.InAppPurchase, prodIds); Error msg: "Sequence contains no elements" If I trigger a purchase with hardcoded values testing in Windows var purchase = await billing.PurchaseAsync(productId, ItemType.InAppPurchase); The purchase popup appears, the store item flashes and disappears and I get the message - see image below... Nothing special in code, standard implementation and both iOS and Android apps work fine. The purchase item productId is the same across all stores too and no errors/issues cited in the MS Store either. Anyone else have any insight into this? Apart from that, this InAppBilling lib will need updating soon since SO MANY rely on it. I'm ok to work on it and provide feedback once I solve this current windows store issue as a priority. I have also tried using the InAppBillingPluginExtended<https://github.com/sherwyn33/InAppBillingPluginExtended> but same errors/issues. image.png (view on web)<https://github.com/user-attachments/assets/7cbe34ff-06d9-47dc-904b-1e4d3fabca6c> — Reply to this email directly, view it on GitHub<#2783 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AGKUGCI3EPGG7QXAS3PHWY3376C4DAVCNFSM6AAAAACATBNBAOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKMJVGQ4TSNI>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[rokmeglicbit]

There is also https://shinylib.net/client/inapppurchases/ - Shiny available.

Shiny.Mobile.InAppPurchases is cross-platform in-app purchases for .NET MAUI — consumables, non-consumables and auto-renewable subscriptions — built on the current generation of each store’s API: StoreKit 2 on iOS and Google Play Billing Library 9 on Android.