Edit: @boopboop @angus
Revisiting this to focus more on the short term. For the co-op right now it is more important to be ready as soon as possible to collect new memberships and renewals asap, with lowest technical risk, never mind about accounting for them. Let’s use the Stripe API we know, and not do an ambitious Payment and Accounting SAAS at this stage.
There are a couple of options on how to do that. One of them involves quite a lot of work in building our ‘checkout’ , with the advantage of better control over the UX flows. The other uses some Stripe SaaS services which reduce the dev effort but do involve a handoff to a Stripe SAAS checkout. In the short term we’ll have to rely on giving worker access to ‘default’ stripe dashboard services to support and account for payments. We would have to allow some Dev time to help with admin and membership queries. We also need to think about extracts for mailshot campaigns to promote renewals.
Where we are now:
Today, Resonate suffers from ‘Dumb’ / manual account mapping and the task of reconciling thousands of individual income transactions - labelled ‘Stripe Income’ or similar with unfriendly ‘Payment Intent’ codes.
To manage membership, there are potentially insecure extracts of membership data to spreadsheets and tedious reconciliation with the payments and accounting treatment of the income / share issues. Non-stripe income from bank payment has much lower transaction fees but involves tedious manual reconciliation.
The user experience in the current WordPress is disjointed and broken - forms are not rendering history of shares and payments in a recognisable ‘statement’. Occasional payment failures are difficult to trace and rectify, and system administrator privileges and valuable developer time is consumed in creating extracts / debugging.
Exchange rates (and VAT rates) are hard coded and are incorrect / out of date. We do not systematically track location / country of income in the accounting.
Payment and Accounting for Short Term - Relaunch
Short Term Option 1
In this short-term option, we extract the previous year’s (ie only the current) memberships and put them in a temporary membership table. We create a new version of the checkout we used to have on WordPress. We continue to make very simple use of the stripe payment intent API, as we have today, for the credit top ups, but we add metadata to record in the PI ‘what this payment was for’ - to make reconciling the Stripe payment extracts easier later on. (still manual). There is quite a lot of checkout and pricing code to write, test and secure if we are adding all the memberships. For more discussion on this and pro’s and con’s see the
deck, slide 5.
Short Term Option 2
This short term option makes use of the Stripe api (user, product. prices and the checkout) and also uses of a Stripe-hosted checkout page. Pricing and tax (and promotions, discounts etc) are all handled by Stripe. This reduces the amount of code we ahve to write, test, host and secure.
As a by-product, it also makes the stripe extract data better for reconciliation and makes it easier for workers using the
Stripe dashboard to find what they need to fix problems in one place. It’s true there is a UX hand-off after the order ‘preview’ but the Stripe pre-built checkout page is widely used and is familiar to consumers, and can be branded/styled/customised.
How would we handle conversion and migration of existing memberships for a ‘renew now’ campaign? We could upload legacy membership details (only the current ones) to the orders and accompanying user tables on Stripe.
See the
deck, slide 6.
Mid Term Option
There is a possible mid-term solution that would allow us to bill and account for all our credit top-ups, membership and supporter share products and would be a Xero-specific simplification of @auggod’s stripe api code. It involve the creation of a contact in the Xero SAAS corresponding to a Resonate user, then the creation of an invoice for the products they have ordered (products and pricing all in prior set-up in Xero). We’d use our Stripe account via Xero to make more sense of the payments.
It could provide a wider choice of payment methods for the user, including bank payments and recurring renewals.
However, this SAAS solution is not suitable for a fix to native Resonate credits accounting - no credit transfers yet. Nor does it provide any local ‘cacheing’ of all the data held in the SAAS.
See https://developer.xero.com/documentation/guides/how-to-guides/how-to-integrate-my-pos-system-with-xero/#overview
These API’s are new to us (=risk) and would need some research and investigation. See the deck, slide 7.
Payment and Accounting API Roadmap (post-relaunch)
See the deck, slide 8.
After settling in with the relaunch solution we would evolve a longer term, fuller solution. In addition to handling credit top-ups, membership and supporter share products it would feature a ‘future-proofed’ non-SAAS-specific API gateway. (Such an API gateway could also be a connection point to other coop back end accounting systems, making it easy for them to sell our products on their systems.) It provides better handling of listening credit accounting, including transfers and donations. The user account would be presented from API responses from the SAAS with some ‘cacheing’ and more ‘custom’ rendering to improve on the default SAAS payment model.