Well, being a ‘domain expert’ is just as valuable, if not more so, to ensure the right things get built 
Wonderful coincidence that you’re a E. R. Schumacher fan. I have that book, but should just give myself the time to read it.
Regarding FB scale it was just me poorly phrasing it. I think its because I see so often people mentioning “Yes, but this will not win from GAMAF”-like statements. @darius did an AP Conf talk Let's Play and Win Our Own Game which I recommend watching.
This depends on case by case basis, I guess, and where the mentioned concept of Payment Schemes might be useful.
Take the example of a small FOSS Community with passionate members supporting a new project. Mere cents will not fund the project at this early stage (funding is not always needed, but in general a big problem that the free software movement struggles with). Some other large and popular FOSS software may have corporate users who are submitting urgent RFC’s to the issue tracker and putting the maintainer under pressure to implement them. Well… pony up big time, and maybe it will be implemented.
Maybe “Payment Schemes” is a wholly separate (sub)domain to the “Micropayments” domain. All kinds of mechanisms can be attached to this concept. For that matter I will post a link to this discussion in the Snowdrift.coop Matrix group. Think they will be interested.
Snowdrift is implementing Donations for (software) projects, and their primary model (they are investigating multiple models) is one of Crowdmatching. As the popularity of a project grows - measured in the number of Patrons - the amount donated per Patron grows with it. This is similar to the idea of “paying for value” in PonyUPS. Here’s the concept:
This is just one example of possible Payment Scheme mechanism. There are undoubtedly many others to be discovered, like e.g. in the earlier example of the small FOSS community having early-bird participants pony up relatively large amounts of money on their interaction, so the project gets enough money to bootstrap itself, and then later on - once a certain treshold is reached, these early ‘investors’ either get very low, rebated rates or might even earn some or all of their investment back.
Discovering use cases
I think this whole idea has potential. But it also involves a ton of work to realize this as actual working software. One thing that is most precious, and a big barrier to find project contributors and get this off the ground, is Time. Time may be the most precious commodity in the world, nowadays!
Here’s where you as a domain expert, and others like you (such as me, atm) can prep things, to provide the incentives and initial boost for technical contributors to join PonyUPS: By elaborating the domain, and clearly demonstrate the Key Benefits for the various ‘stakeholders’ to get involved.
There are tons and tons of use cases for Micropayments and Payment Schemes to be added to numerous other business domains. It does not require any technical knowledge to brainstorm them and document in brief snippets of text. Like I did in previous post for FOSS Community.
From a brainstormed list and on a domain-by-domain basis we can take these use cases and elaborate them further, like providing more detail on the Payment Scheme mechanics, and - based on usage metrics of running applications - estimate how much money is involved, etc. Things like that.
A good starting point for that is the ActivityPub Application Watchlist that has the whole range of federated applications, covering multiple business domains. Some of these are already directly implement Group / Community concepts, but even if they do not “Community has no Boundary”… the entire Fediverse or individual instances are communities too.
Update:
Via this toot thread I bumped into this SwiSo issue about the ethics of LiberaPay and OpenCollective, which led me to:
(I will add this to the curated delightful-funding candidate list, that I maintain)