Edit history

Support alternative payment providers for self-hosted instances (e.g. Wero) has not been edited, so there are no earlier versions.

Current version | Original by penguin
Show

Support alternative payment providers for self-hosted instances (e.g. Wero)

Current problem

Fluxer currently provides a Stripe integration for handling subscription payments on self-hosted instances. While Stripe is a well-established and convenient solution, relying on a single payment provider limits the flexibility of instance operators who may prefer or need to use other services. This is particularly relevant for European operators who would like to use European payment infrastructure and reduce their dependency on US-based providers. At the moment, there does not appear to be a built-in option to configure an alternative payment provider such as Wero.

Proposed change

I would like to suggest adding support for alternative payment providers alongside Stripe, with Wero as one potential option. Wero is a European payment solution developed by the European Payments Initiative (EPI). Its merchant payment infrastructure also includes support for recurring payments, making it an interesting candidate for subscription-based services such as Fluxer's Premium features. Ideally, Fluxer could eventually introduce a provider-independent payment architecture, allowing self-hosted instance operators to configure their preferred payment provider. Stripe could remain the default, while additional providers such as Wero could be enabled optionally. This would increase flexibility for self-hosted instances, support European payment infrastructure, and potentially make it easier to integrate further payment providers in the future.

Platform

API, Self-hosting

Additional information

Wero could be an interesting example of an alternative payment provider, particularly given Fluxer's European origins. Official Wero developer documentation: https://wero.readme.io/ Wero provides merchant payment APIs and documentation for recurring subscription payments. Of course, I understand that integrating an additional payment provider is not as simple as adding another payment method. Subscription lifecycle management, webhooks, refunds, failed payments, and payment provider availability would all need to be considered. I am not suggesting that Stripe should be removed or replaced. The idea is simply to provide more flexibility and choice, especially for self-hosted instances. I would be interested to hear whether a more modular payment provider architecture is something the project might consider in the future.