Thanks for you comment, especially the references to existing projects is very helpful. Could you give me a link to the Takahe and Mitra projects?
Integrating Payment Providers
On the topic of integrating payment providers, I’m concerned that the integrating any set of payment providers will reduce the accessibility of the entire software.
Integrating a crypto payment system is controversial in-and-of itself and I’m also doubting whether the effort required here would be worth the development time needed to implement it.
And other payment processors, such as Stripe, PayPal, Klarna, Direkt all have the problems of accessibility and privacy. Most of these systems are only available on certain markets or for certain currencies or for people with a bank account, credit card etc. And while it is completely legitimate for a single offer to restrict buyers to use a specific payment provider, doing so at a software level is very restrictive if not patronizing. If I only implement a subset of all existing payment providers (e.g. Stripe and not AliPay), I’m telling people from those places that my software is not for them.
Instead my idea is to allow for offers and invoices to include “payment details” as opposed to using a payment provider - such as an IBAN, PayPal username, address to send money to, etc. There are quite a few privacy-focused services that already use this approach, for example ProtonMail and Nitrokey. This would also allow people to use an instance of this software without ever running non-free software on their own devices, as for example authorizing a bank transfer can be done without using online banking.
It certainly will not be part of the grant to implement support for any of these payment processors. If this project grows, I’ll be considering the possibility to add payment provider options.
See: socialcoding