Collective dues
Background
Collective dues is a donation scheme that changes the way the chapter collects money. The chapter approved adopting this scheme at a prior meeting.
tl;dr
Before collective dues, members would primarily pay dues and renew their membership directly with National DSA, and optionally elect to contribute dues to our local chapter. This requires members to keep track of two different dues processes. It also requires members to navigate an obscure dues waiver process, which may discourage people from joining.
After collective dues, members would directly interact with the chapter to manage their dues. We would automatically manage the dues waiver program for them and interface with National DSA on their behalf. We would also implement the local dues split recommended on our website to maximize the amount of additional money that goes to our chapter general fund.
More info
- Original motion (Google Doc; SV DSA access req'd)
- Proposed implementation with Google Forms (Google Doc; SV DSA access req'd)
- Local dues page
Technical details
Payment processor and donation collection
The chapter currently uses the iATS payment processor to handle donation processing. This processor offers lower rates than other providers (comparison pending review of contract).
iATS offers the Aura payment form builder (manual PDF). This form builder is comprehensive, but is difficult to configure on our end and difficult for members to pay dues with.
Donor management
The chapter manually maintains donor information for recurring donations. We would have to scale this up to accommodate all of the members of the chapter.
Areas of investigation
-
is iATS the best option to use here? vs something like DonorBox - resolved in following comment, using Stripe
-
how do we present the collective dues collection to members? - decided on anonymous page implemented in
membership_ui
at/newbies/collective-dues
- decided on anonymous page implemented in
-
what are the different APIs or methods that we can use to collect donation information? APIs, forms, etc - using Stripe Billing subscription APIs (incl. Stripe customer, product, plan APIs and Elements React components for collecting billing information)
-
how should we manage donor information for collective dues? - storing billing information and product / plan information in Stripe
- using email address as the lookup key for Stripe customers (no need to store a separate Stripe customer ID in the database)
- store remaining membership data in the existing columns of the Member table in the DB
-
should we integrate donor management into the membership portal? how should we do this? - eventually, but it's not necessary right now. Stripe has a self-service subscription portal in beta (https://stripe.com/docs/billing/subscriptions/self-serve-portal). Can eventually expose APIs through the server to expose information for admins / members to view their collective dues info
[ ] which other ambiguities do we need to resolve before we can take action on this?