#Xero api create invoice full#
#Xero api create invoice plus#

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. …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. Xero, who in addition to accounting, provide SAAS invoicing payment solutions for small businesses Xero There are other SAAS options available as extensions to our existing payments and accounting solutions, for example: 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. It would also provide a lot of possibilities for more sophisticated store set-up. Fit? This would provide secure payments integration with proper PCI card handling, security, multiple payment provider integrations. Implement an e-commerce SAAS web store solution with membership as a ‘product’. 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. The bigger question is fitness for purpose and future stability of the plugin. 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. This has the advantage of being well-integrated with our community service, but couples us rather tightly to Discourse in future. Using a generic Discourse subscription management feature: Discourse Meta – 19 Nov 21 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 2: Discourse + Plugin This is likely to give the best fit to our (current) user stories, but is probably the most effort.

Implement the membership tables / classes as originally specified in golang / postgres as a further iteration, completing the user-membership api as originally envisaged.

use a ‘commodity’ proven open source / SAAS hosted solution.

#Xero api create invoice plus#

adapt it in Discourse, using a plugin, plus standard membership features.… so I am checking here for you for thoughts and comments before shaping up a payments epic. The user-api will record the fact but not handle the process of becoming a member or becoming a non-member.īefore 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. It is not modifiable by a non-admin via the api. There is merely a field that tells you if someone is a member or not. The ‘memberships’ part of the user-membership api was intended to support the member signup and membership admin user confirms it is only the user / iam functions that have been implemented and there is not yet any ‘membership’ functionality:

#Xero api create invoice full#

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).