The goal of enabling some kind of financial integration for flathub.org is to
permit a combination of donations and payments for flatpak applications and
platforms.
Financial integration will permit application developers to designate apps as
being pay-for, or to indicate how donations to their flatpak should be
disbursed. In addition it will allow flathub.org to receive donations to
assist with hosting and other costs.
There are a number of scenarios we are considering for this document, covering the above use-cases.
- A user wishes to make a donation to flathub
- A user wishes to make a donation to the authors of a particular flatpak
- A user wishes to purchase access to a particular application which is provided for a one-off payment
- All of the above, but on some recurring model (subscription).
In addition, for any given payment to a flatpak (author) there may be some formula governing how funds are allocated to the platform (FDSDK fr.ex) or to other associated projects (GNOME, KDE, etc.).
We are currently considering Stripe for processing payments and dealing with the monetary aspect of this project. Stripe Connect looks plausible for facilitating these multi-party transactions in a reasonable fashion, though there are concerns listed below.
Given the global nature of the flathub marketplace, any financial transactions need to be able to cope with payments coming from any jurisdiction, and being made to any combination of jurisdictions. Stripe have some information on their account capabilities page, under 'Transfers' about cross-border transfers in which they explain that to make payments across borders requires one of two kinds of platform accounts, which have limitations.
- For inter-EU countries only (SEPA, which excludes the UK) an EU based platform account could be used with ease.
- A US based platform account could cope with sending to almost any country which Stripe supports, except that recipient accounts must be configured to permit this, which places other limitations on the receiving account such as it being unable to process card payments for itself.
- Any location platform account, paying to any recipient account, providing the recipient account is set up to process card payments itself.
In addition to the above limitations around cross-border transfers, there are limitations in the construction of transactions when subscriptions are taken into account. In the first instance, subscriptions can only set a percentage fee for the platform, unless we have a webhook reacting to subscription creation which then configures the invoice for the subscription each time. Also subscriptions invoices do not seem to support payment groups, thus not permitting the structuring of a multi-party invoice. (We would still be able to have a subscription for app + flathub, just not also for FDSDK).
This may mean that subscriptions would need to be handled by our platform which would require user interaction with stripe upon renewal. This could lead to either choosing to not process subscriptions ourselves at all, or to only support them in the basic case of "X to flatpak author, Y to flathub" with no option to also provide "Z to FDSDK" or similar.
Other concerns:
- No matter where our platform account lies, there'll be a need to confirm what, if any, tax implications there will be to processing these donations and payments.
- Whichever legal entity owns the platform account is also responsible for dealing with disputes, refunds, etc. This means that if a user buys an app and then tries to get a refund, the refund comes directly from the flathub platform account, and then a charge-back to the app author will need to be done. Fees are lost in the process, and that's all on flathub. (though we could charge for fees up-front, if we wanted to be transparent)
- Some countries can only be interacted with in certain currencies, which may make things complex for dealing with showing pricing etc.
- We (flathub) would be responsible for enrolling people into Stripe in the correct ways, and joining the accounts together. This will require significant care and audit trails to ensure we can comply with external audits should they need to occur.
An alternative to the complexities of multi-party payments etc. would be to collect all payments into the platform account - i.e. donations, payments, etc. all go into the flathub account, and then on some trigger, either the user hitting a button in the webapp, or a timer, or threshold being exceeded, we then make a transfer to the app developer. This has the benefit that Stripe's subscriptions, etc. would all "just work" but the downside that the entity holding the Stripe provider account would need to be responsible for the money in the interrim, and there could be more stripe fees, though that's not clear yet. In addition there are legal time limits in holding funds in this manner so we'd need to be clearly documenting how and when funds get disbursed.
There are complexities involved in being a platform account, such as needing to police the connected accounts carefully, to prevent bad actors from draining the platform account. Some of that is explained in the reserve balances documentation.
We can use SetupIntents to prepare off-session authorisations and then use those with proper PaymentIntents to construct scheduled payments without using Stripe's subscription APIs, but that requires the user to have associated a card or bank account with Stripe, where subscriptions permit Stripe to email the user and request they turn up to top up their account. Either way, payments might fail and require us to also email the user to request they come and sort stuff out.
Regardless of the approach we take to the above, we need to organise managing stripe customer records, setupintents, etc. this means building a majority of a web-shop excepting where those pages can be provided by Stripe themselves. Obviously where possible we should defer those functions to Stripe themselves since that gives us the greatest sense of "we're not messing you about" unless we really want to build things like 'card wallets' etc. to deal with things.
We might be able to build a lot of the components using Stripe.js which has pre-built UI components for at least some of what we need.
The tax situation worries me. In particular, VAT and sales tax on app purchases, and what jurisdictions they'd be due in.