Over the last month, using Integromat and the Wave App, I developed the scenarios in Integromat to sync my WA membership database into my Wave instance.
This scenario can be run as and when required (but definitely before a billing cycle).
For WA members not in the Wave instance - it adds them. For WA members already in the Wave instance it updates them with the crucial invoicing information.

The second scenario processes a specific Membership level from WA and based on a field value for each member invoices a specific item to that member which is either the annual, semi annual, quarterly or monthly membership fee. There is also an option to invoice a discount if needed (this year due to Covid we discounted our renewal rates). These invoices are then emailed to each member.
The Wave App is free and thus we can have an instance of that for each chapter.
Each Wave instance can have it's own currency and target bank account for deposits.
Pricing same named items can vary as well.
Wave has it's own payment gateway for Canadian and US based accounts.
For UK accounts they take payments through Stripe. Stripe would probably also work in any other country where Stripe is accepted (but seems to be limited). payments made through either the Wave gateway (actually much easier to use than PayPal) automatically reconcile to the invoice. The web interface also supports manually applying payments from other sources to the invoices. Optionally Wave can also be used as a full blown cloud accounting application.
By using Integromat to initiate the invoices - it could also be possible to use other tools such as Invoice Ninja - just modify the Integromat scenario. Invoice Ninja integrates with many other payment processors (including PayPal which is just about universal). Invoice Ninja does however have a limit of 100 customers (ie WA members) per instance in the free version.

Still have to figure out how to handle invoicing for donations, events and store.
However we do not use any of these (but some of our other chapters do).
Donations and store can probably be handled with the Wave checkout option - sort of like a PayPal button.

A week ago we went live with this integration and ran the annual membership renewal.
Interestingly the payment response has been significantly quicker that in previous years using the native WA invoicing. With Wave there is a link in the delivery email that allows a member to pay with a single click from the email. After that just select CC or bank withdrawal and you are done in just a few minutes.

We currently have 4 of our Chapters each with their own WA site. Since WA doesn't have a national/regional/local Chapter option, we created a 5th WA site and mickey-moused it to work for all of our members by using Chapter prefix codes on all of our new events and membership levels. We will export members from the 4 sites and import them into the 5th site. Wish there was a way to export event data into the 5th site to preserve registration history and event details (vs. copy/paste of just event details). Once we merge our members, we will no longer use the 4 other sites. There may not be much of a demand for a site merge feature, but it would have been a whole lot easier if there was. :-)

I have been wracking my brain on how to work around elegantly Wild Apricot's configuration to accomplish the idea of a "master" site and subsites all within 1 Wild Apricot instance.

1) The database can be configured to have either a chapter assignment attribute OR a different set of membership levels for each chapter.

Using the database field approach one can register through a central, agreed upon set of membership levels consistent for ALL chapters (or at least the majority) and then the member records via drop down or radio button which chapter they are assigning themselves to. You can do some interesting things like being assigned (and pay via calculated charge membership field) to multiple chapters if you want. The MAJOR issue with this is that page level access control CANNOT be set with saved searches so membership groups have to be used instead. I do believe membership groups CAN be set on registration or renewal but cannot be automatically defaulted to a set level. This is an issue that could be solved with some page level Javascript (a very small hack).

Using membership levels is another approach where each chapter derives their own set of membership levels from a master set and then has a large degree of configurability. Membership levels are the chapter identifiers then.

Access control works seamlessly in the website with membership levels.

2) All access control to websites can be managed via membership level or the membership group and unsurprisingly this is the easiest and best fit. Chapters can have their own page templates derived from a master set of templates and the "subsites" can be quite rich with their own set of controls.

Escalation has to happen to a master website coordinator to make new pages or changes to page templates. This may be a *good* thing!

3) The events system has to use membership level/groups based on decision in 1 OR instead use the tagging system. Tagging system can be fragile and leak events into wrong chapters.

The main issue here is that any administrator with event management rights (or full admin) can see all the events and has to be adept at finding and managing their own events. Lots of chapters means LOTS of events. The upside is that people can copy event ideas from each other using duplicate but the event UI can become a mess. On the other hand with adequate training and policies this *could* work.

Events access control via gadgets show the appropriate events to each subsite chapter, with a BIG plus that events across the whole org seamlessly float up to a master event calendar.

4) The payment gateway limitation is the *single biggest* roadblock. Since only 1 currency and 1 payment gateway per account is allowed, the owner of the payment gateway has to be responsible for "doling" out funds to each chapter using a very well defined identifier. This must happen in the reporting on the payment gateway. Most (if not all payment gateways) support ONLY 1 bank account so this must be done OUTSIDE of the payment gateway. This is a show stopper.

If Affinipay supported multiple bank accounts for withdrawal based on a tag, a single payment gateway would be ok as long as an indicator for every transaction showed where the transaction goes (HQ, chapter 1, 2 etc) and if the payment gateway could just dump money into the right account, financial reporting could support the reconciliation effort.

Saving costs of multiple payment gateway setups and administration as well as single point oversight of all financials could be good (unless chapters didn't trust each other).

5) Reporting can be done in 1 site with membership summary quite well IF and ONLY IF the membership levels are selected for each chapter (described in 1). If a consistent set of chapters with calculated charge fields are used for all chapters, that's even better. The Excel Dashboard we adapted from Wild Apricot API samples can be effectively used for custom rollup rerpoting.

6) Training and operational excellence is a MUST in a single site multi-chapter Wild Apricot system. You have to do things correctly in terms of adding a chapter, adding pages, inheriting membership levels for a new chapter, modification of existing levels.

Setting up 1 set of levels seems like a better way to go but that assumes a business model transformation across all chapters which may not be realistic.

It seems doable, but the payment gateway roadblock seems to be the thing that is the most critical to resolve, whereas the others are not so bad.

Setting up 60 chapters individually with cloning and then reporting across them all seems great, but financially it just doesn't scale because the per contact cost at the smaller payment levels is dramatically more than at the 15k+ levels. The larger the org the less appealing a multi-site approach looks and the more difficult it is to manage.

I can see the light at the end of the tunnel if the Payment Gateway issue is resolved, honestly speaking.

Ditto for us - need multiple payment gateways and also multi currency support. Also ability to protect membership data of chapters ie much more granular capability setting for Admins.

So far no movement from WA on any of these needs other than 'not happening any time soon.

Note that this 'wish' was originally posted by WA almost 8 years ago.

I am also researching a replacement solution - currently 6 chapters using WA and on top of that the recent ~30% price hike.

We currently have the first pass of our requirements document. Sending it to other chapters today for review and comment.

So far have identified about 8 other vendors that may fit our needs.

Expect to have comments from other chapters back early next week and will then forward consolidated requirements to above vendors with expection of having their responses by mid May.

I would be happy to share all this information with anyone else on this forum - just send me your email address - robinsapiro+wa at gmail dot com

Our 5 Chapters (500+ members) voted on combining our existing 4 WA sites into a clunky single WA site using the existing WA options. The largest Chapter has refused to go with a consolidated WA site because of the inability of each Chapter having their own payment processor/account (PayPal in our case) for Chapter dues and Chapter events. Sadly, I have a feeling we may start to look beyond WA now. We want to present a single website with Chapter pages/events vs. having members & the public search around 5 different Chapter websites and our "corporate" website. We need a consolidated membership database to invite all Chapter members to events, All Chapters newsletter, etc. as we move forward.

Dmitry - This type of application would be a hit for the non-profit sectors that can not afford 30-50k for a custom software system to manage multiple chapters under an umbrella organization.
Can you consider developing this for our 6300 member, 53 chapter non-profit ? I know of at least one other Canadian non-profit that would also use this type of platform.
Cheers- Jim

My organization site is currently a WordPress multisite. It's a main chapter then has 5 chapter subsites. We're going to be adding four more chapters this spring. I came here to see if WA allowed for multi-site b/c managing the WordPress site has it's challenges too. One thing though is that every chapter has it's own membership, paypal gateway etc. which appears WA does not...so I guess I'll be sticking with WP for now.

Another workaround would be to perhaps send additional data to, in our case, PayPal. When I download their CSV file of all activity, there are numerous available fields that are blank. Does WA have a way to send additional info, such as a chapter field in the membership database or an event tag? That could help to sort out PayPal transactions.

No updates here, sorry.

Any further news on this subject? Our organization has 5 Chapters and 500+ members. Four of our Chapters are now using their own WA sites. We would love to pursue a "national" or "umbrella" top level with Chapters still doing their own websites under the "national" concept. We are looking for a single membership database and Chapter ability to use their own PayPal (or other) account for "their" events. We'd love to see the ability to provide a combined calendar of events. E.g., we offer camping trips put on by each Chapter, but we'd like to invite all in the organization via the joint membership database. Along these same lines, the ability to subscribe to a joint calendar on our mobile devices - iphones, ipads, etc.

Dmitry As you know I have loved Wild Apricot for more than eight years and send people to you all the time. It is frustrating to combat Board members in our org about the lack of multi-chapter management tools. There are other software options learning from WA and competing who are looking at this option and we do not want to move at all. We have a huge membership drive this year and plan to double our membership so the last thing I need is all of our local club administrators having to learn new software. At least please let us know when this is on the horizon for development. These comments are positive and on point. We mainly need central membership processing with local branch managing events and payments to go to their own club bank account.
Thanks again though to all WA staff for a fabulous front runner to any other software - you've been the leader for years.

Allow for multiple chapter accounts and event registration with unique Paypal accounts for every chapter.

I read :) thanks for such an elaborated comment
For now, we're not planning to do anything in this area (chapters), but your comment will help when it comes to analysis and planning.

As you are collecting information on this concept here is another scenario for your consideration.

Our organization has two divisions:

a) An annual conference that meets in a hotel.

b) A club that provides year round services to those of our members who want more intensive services.

Registering in the conference confers membership in the organization. Registering for a monthly or greater membership in the club confers membership in the organization. While we do offer memberships separately from these activities very few people take advantage of this as they view the organization primarily through the lens of the conference or the club. While we could separate out our annual organization’s membership fees from either the conference or the club we have observed that doing so puts a constraint on our ability to market either activities: in our earlier years we noted that it was a resistance point to either state the membership charge separately or to have to explain why the membership fee was even necessary so we now currently incorporate membership into our user fees. The way that we can justify incorporating the membership fees into usage fees is that we make it clear to our members that we are taking this fee out of their usage fees and we track internally the transfer of funds to the parent organization, which is a budgeting exercise to cover the corporate expenses common to both divisions and to the membership as a whole. Furthermore our larger organization does function as a membership organization with regard to meetings, membership voting, etc.

In effect our two divisions are sort of “chapters” of the larger organization. The larger organization has an annual membership fee, the conference charges differing event admission fees, and the club charges differing monthly usage fees. In our case our divisions are part of the same corporate entity. I would also add that it is conceivable that we could add additional conventions to our list of divisions.

We are currently using Wild Apricot for the club only. We can do this by employing the fiction of treating our monthly usage fees in the club as “membership” fees in the club when in fact they are usage fees to the members of our larger organization who choose to use the club. Since Wild Apricot does not support auto generated billing for anything other than memberships this was the only way that the club could take advantage of auto generated billing on a timed basis.

We do not use Wild Apricot for the conference division mostly because we have detailed workflow requirements for literally hundreds of sessions at the conference that are not handled currently by Wild Apricot. My comments below assume that we would eventually switch to Wild Apricot for the conference division.

Unfortunately all of the above means that we have to manually combine our membership roster from both divisions and perform occasional accounting reconciliations between our divisions. Given the above, admittedly jury-rigged, setup features that could be useful to us would be the following:

1) Certain event registration types in a “chapter” confer membership in the larger organization which shows up in that organization’s membership roster, along with the corresponding bookkeeping entries. General organization membership fees could be either be listed separately and automatically added to the event bill or the organization could simply incorporate them (as we have done) into the event fee; this choice would be an administrative setting. Internal accounting data on membership fees would follow these settings.

2) Certain membership types in a “chapter” confer membership in the larger organization which shows up in the larger organization’s membership roster, along with corresponding bookkeeping entries. General organization membership fees could be either be listed separately and automatically added to the division’s membership bill or the organization could simply incorporate them (as we have done) into the division’s membership fee; this choice would be an administrative setting. Internal accounting data on membership fees would follow these settings.

If you have read this far, I thank you for your attention.

Hi Duncan, thanks for the feedback. We cannot really say when a suggestion is going to be implemented, sorry.

I am excluded from the general discussion area for some reason.

This functionality is crucial for our non-profit - we have started evaluating competing products that offer this functionality out of the box (e.g. silkstart).

What we need:

A national or central view of the full database with existing WA admin and reporting functionality.

Assignable admin rights at local chapter level with the ability to view/edit/maintain member, event, money (donation and finances), email and site data, per existing WA admin functionality but only for that chapter's members. A local chapter dashboard would be good. Essentially a "mini" standard WA view of one segment of the database with rights and views limited to that chapter's data. Custom subscriptions and charges for each chapter, together with either a flat-fee or % contribution to national level would be good too.

Ideally also we'd like to restrict chapter admins from being able to export data to comply with local privacy legislation.

Any idea on if or when such functionality might find its way into WA?

We have the same need. We have six regions distributed throughout the country and in each of those regions we have a number of councils (equivalent to branches) and we need to limit the administration rights of each Regional Secretary to have access, creation and update rights on the membership of their region and the Council Secretary the same rights but only to the membership of his Council. Basically we need to be able to curtail administration rights for administrators at national level, regional level and local level
I believe we could have it done in two ways,
1) Each secretary could have a group of members linked to his level of administration rights or
2) Each member could be allocated to a secretary (An administrator) with full rights or partial rights to create and update the profiles of those members.

It would require allowance for for a member's information to be accessed, changed etc. by more then one secretary (Administrator).

Regards,
Alvaro Peres
aperesx@gmail.com

I am administrator for two WA accounts. Both of them have members in different areas - one has four regions in the US, the other has members in 27 countries. Both accounts would benefit if we could give the regional or country representative access to just the data relevant to that area.

No updates, sorry. Still waiting on this :(