In preparation for the payment accounting api epic I’ll summarise the ‘as built’ state of the current user api (first iteration) vs the full scope for user and membership api we have in the full spec (see link in post above).
The ‘memberships’ part of the user-membership api was intended to support the member signup and membership admin user stories:
@merefield confirms it is only the user / iam functions that have been implemented and there is not yet any ‘membership’ functionality:
There is merely a field that tells you if someone is a member or not. It is not modifiable by a non-admin via the api.
The user-api will record the fact but not handle the process of becoming a member or becoming a non-member.
Before we build anything on memberships I think we should check if we could simplify this even further, or even realize these objects with ‘out of the box’ membership solutions elsewhere. … so I am checking here for you for thoughts and comments before shaping up a payments epic.
At the moment I see three main options:
- build it bespoke
- adapt it in Discourse, using a plugin, plus standard membership features
- use a ‘commodity’ proven open source / SAAS hosted solution
Implement the membership tables / classes as originally specified in golang / postgres as a further iteration, completing the user-membership api as originally envisaged. This is likely to give the best fit to our (current) user stories, but is probably the most effort. It might work well as a back-end for the new signup screens attached to the ID server, but involves a lot of payment service api implementation and maintenance and integration with the Xero accounting API’s
Using a generic Discourse subscription management feature:
This has the advantage of being well-integrated with our community service, but couples us rather tightly to Discourse in future. But: as we are leaning heavily in that direction anyway with our community use of Discourse, the strategic risk of ‘lock/in’ could be acceptable. The bigger question is fitness for purpose and future stability of the plugin. E.g. is the treatment of ‘products’ as access to a private category or group sufficiently robust in this plugin? It’s not like a ‘proper’ e-commerce solution, but it might be close enough to our memberships/shares, top ups and ‘artist circles’ use cases? It is effectively ‘free’ for us as an open-source plugin, and easy to host on our Discourse instance.
Implement an e-commerce SAAS web store solution with membership as a ‘product’. Fit? This would provide secure payments integration with proper PCI card handling, security, multiple payment provider integrations. It would also provide a lot of possibilities for more sophisticated store set-up.
Shopify seems to work well with Discourse (Connect Shopify Products to Discourse Groups - Shopify - Pavilion) Cost is initially modest at $360 a year with say 2.5% transaction fees on top of that.
There are other SAAS options available as extensions to our existing payments and accounting solutions, for example:
Xero, who in addition to accounting, provide SAAS invoicing payment solutions for small businesses
Mangopay: Crowdfunding | MANGOPAY API Docs
…which is also open source, and nonprofit.
…who are an EU focused SEPA patreon alternative that we have talked to previously
There are other open source alternatives like
used OK by webarchitects coop, and maybe
Open source accounting solutions like
…have nice invoicing and collections features around the core accounting solution offer, which, like a Xero-based solution, would have the benefit of a pre-integrated accounting ledger. For the Discourse plugin, and other ‘e-commerce’ solutions like Shopify, Stripe invoicing, InvoicePlane and Invoice Ninja, integration with the current Xero back-end accounting system would be required.
Switching to Akaunting might also be possible, or another SAAS accounting solution (many available including Quickbooks, Sage, Freshbooks, Zoho etc) but this would involve additional effort in both selection, familiarisation, integration and migration. I think this isn’t something to take on now - let’s continue to use Xero, and integrate with caution. (Views?)
Tell me if there are any other options to consider here, or if you have any reason to immediately exclude one or more of them. It is of course possible to include a ‘hybrid’ solution, but that might bring further complexity and maintenance burden.
I’m keeping the initial focus on managing our ‘fiscal’ receivables (new memberships and renewals, supporter shares, donations), receipts (the matching payments), payables (credits/reversals and artist payouts) and payments (made) for now.
Later there will also need to be improvements to our internal micropayments and credits, which are only crudely handled by the player accounting at the moment. These will probably be a bespoke solution. I will create a separate component / topic for that.