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

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.

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

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

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