I termed this model "microsubscriptions" when I was pursuing it in the context of website funding.
There are difficulties.
Gaming the system
Folks will absolutely distort their software, buy fake github stars, spam out bazillions of typosquatting packages etc. We know this because there is already a weak financial incentive to subvert: supply chain attacks for cryptominers. Direct cash will be a much stronger incentive for fuckery.
Banking
In general, financial institutions don't like services that aggregate and transmit funds. They attract extensive regulatory burden and more importantly, they attract fraud and chargebacks.
Chargebacks and fraud are expensive to deal with, banks hate it, so they generally tell you to just sod off entirely.
Regulation
You are on the hook too. Anti money laundering laws are complex and can come with criminal charges for failures. Taxes are complicated and you need to keep correct books. Got it wrong? Too bad, you owe the taxman cash you don't have.
Credit card money laundering in general
This is where someone with a stolen card uses your service to launder money taken from it. They sign up with the card, patronise their own software, then run off with the cash. Later a chargeback arrives which is levied against you, not the attacker.
The easiest defense is to limit the subscription amount, so that an attacker with a stolen card can't benefit much. But they can still use you to test that the card is active. A second defense is to hold the funds for a period of time, so that you can pay chargebacks. Even so, you will be looked at poorly by any banks or processor companies if your chargebacks pile up, regardless of whether you could cover them or not.
Trusts
This one is the biggest mistake I see, and I see it again and again.
If you receive money from person A so that you can pay it to person B on A's behalf, you are a trustee. You generally don't need a document to become a trustee and you don't even need to intend to be a trustee. Trusteeship arises from the facts.
What does trusteeship entail? Fiduciary duty. That is a high bar and you almost certainly don't meet it.
Mingling funds from multiple donors without incredibly scrupulous accounting? Problematic. Mingling donor funds with your own funds? You're in deep shit.
Further: trusts have purposes, which the trustee has to abide by. These again can arise from the mere facts. If you said you would take funds from A to pay to B, that's all you can do with it. Can't find B? Stiff shit. B doesn't want the funds? Stiff shit again. You now have money that is like radioactive waste: it's dangerous, you are responsible for it and it won't go away.
----
In general I like microsubscriptions as a model for some things. I spent a lot of time, emotion and treasure on doing it myself. But it is harder than it looks.
You sound like my legal council, accountant, financial advisors, investor friends and former colleagues from the bank used to work for when I was having the same thoughts about building a micro-payments service.
Yes, if you take credit cards, you'll have loads of issues. But for example supporting the eurozone (most of the EU) is both easier and better accomplished by only taking SEPA push transfers. While there is fraud risk, it's significantly less and shouldn't cost you as the processor. Worst case, I think, it'd be the cents you have to pay to send the money back.
And regarding the issue with being a trust: sure that's a thing, but contract terms should be able to fix the problem by making you send it back (minus nominal fees?) if the designated recipient's registered IBAN refuses your payout. And just don't offer to collect money for anyone who didn't register.
One of the most enlightening blog responses I have ever read and so important because there are so many issues where one that hasn't dived deep into the topic likely will not have uncovered going in. Especially from a technical perspective.
Many mock engineering challenges in banking but boy, given the complex environment that they operate it, you can see why the technology stack is a mess that mirrors that environment.
I don't see them as dealbreakers for a sufficiently well-resourced organisation. After all, I wanted to pursue a related model for websites, so I wanted them to be surmountable. But for a startup they would be high barriers, especially since most software folks have never even heard of trusts.
Mind you I had an advantage in that my scheme, payment and usage were tightly linked. I had a protocol that could prove a user had visited a given website, without needing to reveal that user's identity to the website and without the ability for the user to falsify visits. But with opensource software there's currently no good way to verify usage, there's no expensive signal that the code is being consumed. All that's left are cheap signals, easily gamed, like github stars.
At $DAYJOB I've pitched a concept of universal asset accounting which would actually make such a consumption signal possible in theory. For inspiration I was looking to inventory accounting and cost accounting, particularly resource consumption accounting.
There are difficulties.
Gaming the system
Folks will absolutely distort their software, buy fake github stars, spam out bazillions of typosquatting packages etc. We know this because there is already a weak financial incentive to subvert: supply chain attacks for cryptominers. Direct cash will be a much stronger incentive for fuckery.
Banking
In general, financial institutions don't like services that aggregate and transmit funds. They attract extensive regulatory burden and more importantly, they attract fraud and chargebacks.
Chargebacks and fraud are expensive to deal with, banks hate it, so they generally tell you to just sod off entirely.
Regulation
You are on the hook too. Anti money laundering laws are complex and can come with criminal charges for failures. Taxes are complicated and you need to keep correct books. Got it wrong? Too bad, you owe the taxman cash you don't have.
Credit card money laundering in general
This is where someone with a stolen card uses your service to launder money taken from it. They sign up with the card, patronise their own software, then run off with the cash. Later a chargeback arrives which is levied against you, not the attacker.
The easiest defense is to limit the subscription amount, so that an attacker with a stolen card can't benefit much. But they can still use you to test that the card is active. A second defense is to hold the funds for a period of time, so that you can pay chargebacks. Even so, you will be looked at poorly by any banks or processor companies if your chargebacks pile up, regardless of whether you could cover them or not.
Trusts
This one is the biggest mistake I see, and I see it again and again.
If you receive money from person A so that you can pay it to person B on A's behalf, you are a trustee. You generally don't need a document to become a trustee and you don't even need to intend to be a trustee. Trusteeship arises from the facts.
What does trusteeship entail? Fiduciary duty. That is a high bar and you almost certainly don't meet it.
Mingling funds from multiple donors without incredibly scrupulous accounting? Problematic. Mingling donor funds with your own funds? You're in deep shit.
Further: trusts have purposes, which the trustee has to abide by. These again can arise from the mere facts. If you said you would take funds from A to pay to B, that's all you can do with it. Can't find B? Stiff shit. B doesn't want the funds? Stiff shit again. You now have money that is like radioactive waste: it's dangerous, you are responsible for it and it won't go away.
----
In general I like microsubscriptions as a model for some things. I spent a lot of time, emotion and treasure on doing it myself. But it is harder than it looks.