Paid Memberships Pro Group Accounts - WordPress Plugin

How to Configure Paid Memberships Pro Group Accounts for Group Memberships

Paid Memberships Pro Group Accounts is not meant for the usual one-person, one-access sale. It is built for cases where one account owner pays for or manages a set of members. In this guide, we will walk through how to prepare membership levels, configure parent and child access, create a group management page, test invitations, import members, and keep control over seats, codes, and email messages.

This guide is intended for a site owner, WordPress administrator, or developer who already understands the basic logic of Paid Memberships Pro but wants to safely enable corporate, family, educational, or club accounts. It does not cover how to purchase the product or bypass licensing. The focus here is on configuring a plugin you already have, validating the result, and troubleshooting common issues.

The core idea is simple: first separate the group owner level from the group member level, then define the seat, pricing, and code rules, and only after that give the owner a clear page where they can invite, remove, and manage people. If you skip any of those layers, the plugin may appear to be enabled, but the group will not behave the way users expect.

When Group Accounts Are Actually the Right Fit

Before installing the plugin, make sure it actually solves your use case. Group Accounts is useful when membership is not purchased by each member individually, but by one responsible person: a company's HR manager, the leader of a training cohort, the head of a family account, an association coordinator, a club administrator, or an organizational representative. In that model, the owner has a parent level, while invited users receive a child level.

This is different from a standard coupon, because a coupon usually changes the price or applies a discount to an individual purchase. A group code in this plugin connects a member to a specific group owner and grants the required access level without a separate payment at the child level. That makes Group Accounts a better fit for corporate packages, educational licenses, family plans, team content libraries, and private communities with a designated coordinator.

Typical use cases

The clearest example is a company purchasing a block of seats for employees. The company pays for the parent level, receives a code or direct links, and employees register as child members. If an employee leaves, the group owner or administrator removes that person from the group and frees up the seat. A similar setup works for an online school where a faculty, department, or training center pays for instructors, students, or mentors.

A second use case is an association with local chapters. The central organization can act as the parent, while chapters or individual members gain access through the group. For more complex relationships such as "main organization - chapter - member," the developer provides a separate example of a three-level structure. The important limitation is that each level directly manages only the level immediately below it, not the entire chain at once.

A third use case is family or club access. One person pays for the membership, while everyone else gets their own individual account. That matters if the site includes a user dashboard, course progress, order history, member profile, or personal settings. You should not simply share one login across a family or team. That weakens security, breaks personalization, and creates support problems.

When the product may be unnecessary

If all you need is to sell standard access to one user, you do not need Group Accounts. If you are not using Paid Memberships Pro and your membership logic is built entirely around WooCommerce Memberships, it is usually easier to look at WooCommerce-based solutions. If you need a full corporate portal with departments, roles, complex approvals, and training reports, this plugin may only cover part of the job, and the rest will need to be designed separately.

Quick check: if your model includes one accountable owner, seat limits, invitations, and separate member profiles, Group Accounts is conceptually the right fit. If you only need a discount promo code, start with standard discount codes and keep the site simpler.

What to Check Before Installation and Activation

Group Accounts affects payments, registration, email, the account page, and access control. Because of that, preparation matters more here than it would for a small visual add-on. A mistake in levels or on the management page can lead to users registering for free outside the group, owners not seeing invitations, or administrators losing track of who belongs to whom.

Core dependencies

Start by making sure Paid Memberships Pro is installed, activated, and that the main membership pages are already configured. The developer documentation states that Group Accounts requires Paid Memberships Pro to be installed and active, and that the add-on itself is a premium extension. Do not begin with Group Accounts if your registration, account, confirmation, and membership level pages are not already in place.

Review the payment setup for the parent level. If the group owner is purchasing a package of seats with recurring billing, the parent level needs the correct recurring payment structure. There is an important detail in the per-seat pricing settings: if you apply seat pricing to recurring payments but the parent level itself does not have recurring billing configured, the plugin may fall back to the default billing cycle. So before testing seats and codes, verify the parent level's base payment model first.

Levels and Level Groups

Group Accounts requires at least two membership levels: one for the group owner and one for the group member. The child level should be a separate level assigned after the user enters the group code or follows an invitation link. The parent level contains the group settings: supported child levels, group type, seat count, and pricing model.

If your site uses the newer Level Groups feature in Paid Memberships Pro, decide in advance whether users should be allowed to hold multiple levels at the same time. This is especially important on more complex sites where a person might also be a regular member, a company employee, and a buyer of a separate course. If the level relationships are set up incorrectly, access may be replaced unexpectedly or required membership combinations may stop working.

Test environment and user roles

Test the setup on a staging copy of the site or at least with dedicated test accounts. Create separate users for the administrator, group owner, child member, and a member without a code. That way you can see all sides of the process: what the admin configures, what the group purchaser sees, and what happens to the invited user.

Pay close attention to caching. Registration, account, payment, and group management pages should not be served as static pages to every user. If the site uses a caching plugin or CDN, exclude critical PMPro pages from full-page cache. This is not unique to Group Accounts, but it matters even more for group invitations: a member should never see someone else's code, stale seat availability, or a form generated for a different user.

Installation and Initial Validation in WordPress

The official installation path goes through the WordPress admin panel: Memberships > Add Ons, find the required add-on, click Install Now, and activate it. If you are installing the file manually, use the standard screen at Plugins > Add New > Upload Plugin, then activate the plugin from the plugin list. After activation, do not jump straight to invitations. First, confirm that the level settings are available and that the site recognizes the extension as part of Paid Memberships Pro.

The initial validation consists of three short steps. Open Memberships > Settings > Levels and make sure a Group Account Settings block appears when editing a level. Then open the PMPro page settings and confirm that you can create or assign a Manage Group page. After that, check whether the admin area includes the related group management screen if you are using a current plugin version with a separate Memberships > Group Accounts table.

What counts as a successful activation

The plugin is enabled correctly if the administrator can open group level settings, save seat parameters, create a group management page, and complete a test parent checkout. After purchase, the group owner should have access to the group information, and a child user should be able to register by code or invitation for the appropriate level.

If any of those pieces are missing, do not continue blindly. First check that the main Paid Memberships Pro plugin is active, that you have administrator permissions, that the correct level is selected, that the required pages are assigned, and that there are no conflicts in the page editor. For the group management page, the developer documents the shortcode [pmprogroupacct_manage_group], so creating the page manually is fine, but it still needs to be assigned in the PMPro page settings afterward.

Configuring the Parent and Child Levels

This is the most important part of the setup. Most Group Accounts problems do not start on the management page. They start in the levels. The child level should represent the access granted to the invited member. The parent level should represent the product the group owner purchases. If you merge those roles into a single level without understanding the consequences, seat logic, pricing, and codes become difficult to manage.

Child level: access without group settings

Create or select the level that will be assigned to group members. The developer documentation specifically warns that you should not configure Group Account settings for the child level. That level describes the member's access, not the group's rules. If you also sell that same level individually, configure its price and expiration as you would for a standard level. If you do not want it sold individually, consider hiding it from the public levels page so a user without a group code cannot register through the wrong path.

There is an important trap here: if the child level has no price and remains visible on the public levels page, users may complete a free registration outside the group. For some sites that is acceptable, but for a corporate package it is almost always a mistake. It is safer to use a separate pricing page where parent and individual levels are shown intentionally, while the child level is hidden from direct selection.

Parent level: seats, pricing, and supported child levels

The parent level is edited under Memberships > Settings > Levels. In the Group Account Settings block, choose the levels that should be available to group members. Then decide whether the group should be fixed or variable. Fixed seats work well for clear packages such as 10 seats for a department or 4 seats for a family. Variable seats are better when the buyer should be able to choose the number of seats within a defined range.

Next, configure the pricing model. With None, the cost of child seats is treated as already included in the parent level price. With Per Seat, you can add a price for each seat. The documentation includes an important nuance: the final amount is not always automatically displayed on checkout before the form is submitted, even though the charge is calculated when the form is submitted. Because of that, sites using variable seats should explain pricing clearly in the level description, on the pricing page, and in the confirmation email.

Discounts and group seats

The developer notes that discount codes apply to the parent level, but not to the number of seats. That matters in real promotional scenarios. If you are giving a company a discount on a package, the discount needs to make sense at the parent product level. Do not assume that a standard discount code will reduce the price of each seat separately in a per-seat model.

After saving the level, run a test checkout. For a fixed package, verify that the seat count matches the setting. For a variable package, verify both the minimum and maximum values. For per-seat pricing, verify the final charge in the payment gateway's test mode and the wording on the confirmation page. It is better to do this test before you send the link to a real customer.

The Manage Group Page and the Group Owner Experience

Once the levels are configured, you need to give the group owner a clear working screen. The Manage Group page is where the parent user sees members, the code, links, the invitation form, and management actions. If the page is not created or assigned, the owner may pay for access but still have no idea how to add people.

Creating the page

The automatic option is available under Memberships > Settings > Pages. In the additional pages block, click Generate Page for Manage Group. The documentation notes that the page is created as a child of the Membership Account page. That is convenient, because it gives the group owner a logical path from their account area into group management.

The manual option is also valid. Create a WordPress page, insert the shortcode [pmprogroupacct_manage_group], then return to the PMPro page settings and assign that page as Manage Group. Do not leave the page merely published without assigning it. The shortcode may be present, but PMPro will not use it as a system page.

What the group owner sees

On the management page, the owner can see a list of active and former members, search people by username or email, remove members, view the group code and links for supported levels, send invitations by email, create an account for a new member, and regenerate the group code if needed. If the group has more than ten members, the list is paginated, so test not only the first screen but also the list navigation.

Code regeneration is especially important. It is not just a cosmetic feature. It is a way to stop an old code from spreading outside the team. Once the code changes, older invitations and instructions need to be updated. In customer-facing documentation, emails, and internal support notes, it is worth explicitly stating that the new code must be forwarded to anyone who has not registered yet.

What happens to the child account

The child member uses the group code at checkout and receives the selected child level without a separate payment. If the parent loses membership, changes levels, or cancels access, child accounts immediately lose access as well. The documentation also notes that previously linked child accounts do not automatically reconnect if the parent comes back later. The owner must send a new invitation, and members must join again through the current link or code.

Practical takeaway: do not promise customers that the group will "automatically restore itself" after the parent account is canceled and later renewed. For support, prepare a simple process in advance: verify the parent status, verify the code, send a new invitation, and ask the member to go through checkout again.

Emails, Codes, and Invitation Links

A group setup breaks down quickly if the owner does not understand what to send to the member. That is why, after configuring levels and the management page, you should configure email. Group Accounts adds a dedicated invitation template and a variable for checkout emails. That helps explain to the member why they received the link, what access they are getting, and what to do after registration.

Invitation template

Open Memberships > Settings > Email Templates and select the Group Accounts - Invite Member template. Review the subject line, sender, invitation text, direct link, and a clear explanation of who invited the member. Do not overload the message with marketing language. Its job is to get the recipient through registration and reduce support questions.

A good invitation email answers four questions: who is inviting me, what site is granting access, what do I need to click, and what should I do if something goes wrong. If the site supports multiple child levels, explain which level the member will receive. If invitations are sent by different corporate customers, keep the wording neutral so it is not tied to one specific organization.

Variable for checkout emails

For checkout emails, the developer documents the {{ pmprogroupacct_group_info }} variable. It outputs information about the group code, supported child levels, and the correct checkout links. Add it to the emails sent to the parent after a group purchase so the owner does not have to find the code manually. After editing the template, send a test email, but keep in mind that a template test does not always populate real variables the same way a live email does. For final validation, you need a real test checkout.

Code security

The group code effectively opens the door to the child level. Because of that, it should not be published in a public instruction page, on an indexable page, or in a shared chat where it can quickly spread beyond the group. If the code has already spread, regenerate it on the group management page and send new links only to current members.

If you need to block registration to a level unless a group code is present, the developer provides a separate code recipe based on the pmpro_registration_checks filter. Do not add that code blindly. First decide whether simply hiding the child level from the public levels page is enough. If you truly need to block checkout without a code, use the official recipe as your baseline and change only the level ID and the error message.

Practical Example: A 25-Seat Corporate Package

Imagine a site with training materials for professionals. A company wants to pay for access for a 25-person department. The setup needs one accountable owner, separate employee accounts, the ability to send invitations by email, and a clear way to confirm that access is working.

Goal

Create a parent level called "Company Training Pack" and a child level called "Employee Access." The owner purchases the package, receives access to the Manage Group page, and invites employees. Employees register through the link, do not pay at checkout, and receive access to the protected materials.

Preparation

Before you begin, WordPress, Paid Memberships Pro, Group Accounts, and the PMPro pages should already be active and configured. You also need a payment gateway in test mode or another way to validate the order manually. Create test accounts for an administrator, the future group owner, and two employees.

Setup steps

1. Create the child level Employee Access. Do not enable Group Account settings for it. If this level should not be sold separately, hide it from the public pricing page using a dedicated pricing page or an appropriate level display method.
2. Create the parent level Company Training Pack. In the Group Account Settings block, select Employee Access as the supported child level.
3. Select Fixed Seats and set the number of seats to 25. If the package price already includes all employees, leave the pricing model as None. If you need to charge per seat, choose Per Seat and verify the calculation in a test checkout.
4. Create or assign the Manage Group page. If automatic page generation does not work, create the page manually with the shortcode [pmprogroupacct_manage_group] and assign it in the PMPro settings.
5. Open the Group Accounts - Invite Member template and write a short invitation explaining who is inviting the recipient, why the account is needed, and what to do after following the link.
6. Add {{ pmprogroupacct_group_info }} to the parent's checkout email so the owner receives the code and links after purchase.
7. Complete checkout with the parent test account. After confirmation, open the account area and go to the group management page.
8. Send an invitation to a test employee, complete registration through the link, and verify access to the protected content.

Verifying the result

After the test, the child member should appear in the group. On the management page, the number of available seats should decrease or the number of active members should increase. In the admin area, check the Memberships > Group Accounts table if it is available, and also review the user's profile in the user list. In the orders area, confirm that the parent order is tied to the group purchase and that the child member does not create a separate payment.

A detail that often gets in the way

If the employee does not receive access, do not start with the email. Start with checkout itself: did they follow the current link, was the group code entered, are seats still available, and does the parent still have access? Only after that should you look at email delivery. Otherwise, you can spend a long time rewriting the email template when the real problem is in the level, code, or parent status.

Admin Management, Importing, and Transferring Groups

Once the site goes live, the administrator will inevitably run into support tasks: finding a group, increasing the seat count, replacing the owner, importing members, identifying who paid for access, and responding to customers quickly. Recent versions of Group Accounts include a dedicated admin table at Memberships > Group Accounts, where you can see the Group ID, Parent Account, Parent Level, Group Code, seats, and status. That makes support significantly easier than trying to reconstruct the relationships only through users and orders.

What to check in the admin area

In the group table, it is useful to filter by parent level and status. If a customer says "a member cannot sign in," start with the group: is the parent active, are there free seats, which group code is current, and has the group been edited manually? Then check the members list: the child member should show a parent account. In the order list, you can see whether the order was placed by the parent and which code was used during checkout.

The administrator can open a specific group through the parent account and access the Group Accounts panel on the member edit screen. From there, the group management screen is available. The documentation explains that the administrator can change the seat count, update the code, search for members, remove or transfer people, invite new members, create a new user, and add an existing user by username.

Why changing seats does not always change billing

This is an important operational detail: an administrator can change the number of seats inside the group, but the documentation explicitly notes that this does not update the user's subscription price. So manually increasing seats should not be treated as an automatic billing change. If your commercial model requires an extra charge, coordinate that process with the PMPro payment flow first: a new checkout, a level change, a manual order, or another confirmed procedure.

Transferring a group to a new owner

If a team lead changes, you can transfer members to a new owner. The documentation describes the process this way: the new leader completes checkout for the parent level, the administrator records the new group code, then opens Edit Member > Group Accounts > Manage Group for the old leader, selects the members, applies the Transfer bulk action, and enters the new group's code. After that, you need to update or remove the old leader's membership and cancel their subscription if it is no longer needed.

Before the transfer, make a member list and save the old code if your business process requires it. After the transfer, verify access for at least two members: one already active member and one new user registering through an invitation. That helps prevent a situation where the old leader loses the role before the new group is actually ready to accept members.

Importing existing members

For bulk migration, the developer recommends using the Import Members From CSV Add On. In Group Accounts, import is a two-step process: parent accounts are imported first, then child accounts. The parent file needs a pmprogroupacct_group_total_seats column specifying the seat count. After the parent import, groups are created and Group IDs become available. The child file then needs a pmprogroupacct_group_id column to connect each member to the correct group.

Do not mix parents and children in one unprepared CSV. If a child member is imported before the parent's group exists, there is nothing to attach that user to. Before importing, verify the email, username, level ID, group total seats, and group ID on a few sample rows. After the import, open the group in the admin area and make sure the number of active members matches expectations.

Safe Improvements Without Editing Plugin Core

Group Accounts already includes documented hooks and filters, but any custom work should stay small and reversible. Do not edit plugin files directly: updates will overwrite your changes, and a PHP error can break checkout. In WordPress, use a child theme or Code Snippets, and always test code on a staging copy before touching a live site.

Show more members on the management page

By default, the documentation points to the pmpro_group_accounts_manage_group_members_per_page filter, which controls how many users appear in the member table on the Manage Group page. If corporate customers usually have a large number of people, you can increase that value. It does not change the seat limit or add permissions. It only makes the table easier to use.

add_filter( 'pmpro_group_accounts_manage_group_members_per_page', function( $per_page ) {
    // Show more group members on the Manage Group page.
    return 25;
} );

Validation is simple: open a group with more than ten members and make sure you can see more rows on a single page. If the page becomes heavier or customers prefer pagination, remove the snippet or set the value back to 10.

Hide the group code field on checkout only when the logic is clear

The documentation includes the pmprogroupacct_show_group_code_field filter, which controls whether the group code field appears on checkout. But hiding the field should be done carefully. If members enter the code manually, hiding the field will break registration. This filter only makes sense if every member uses direct invite links and you do not want to expose manual code entry.

If you are using the official recipe that requires a group code for a specific level, do not combine it with hiding the field unless you have tested the full flow. Otherwise, you can end up in a situation where the code is required but the user has nowhere to enter it. It is better to lock in one access path first: either a visible code field, direct invitation links, or a separate private checkout.

Text guidance instead of complex code

In many cases, it is more useful to avoid PHP entirely and improve the level descriptions, invitation email, and group owner instructions. Add a short block to the pricing page explaining how many seats are included, who manages members, how invitations are sent, and what happens when the parent loses access. That reduces the support burden and does not introduce update risk.

How to Validate the Setup After Configuration

Your validation should simulate the real user journey, not just saving settings in the admin panel. A good test passes through five state roles: the administrator configures the level, the parent purchases the package, the child member receives the invitation, the site grants access, and the administrator can see the relationship in the backend. If one step is skipped, the problem usually surfaces later for a real customer.

Minimal test scenario

1. Open the public pricing page in a private browser window and make sure the child level is not visible as a free registration if it is not supposed to be sold separately.
2. Complete checkout for the parent level. For variable seats, test the minimum, maximum, and a mid-range value separately.
3. Open the owner's account page and go to Manage Group. Verify the code, links, seat count, and invitation form.
4. Send an invitation to a test email address and complete registration as the child user.
5. Open protected content as the child user and confirm that access is granted.
6. Remove the child member from the group and verify that access disappears or changes according to your PMPro settings.
7. Cancel or change the parent's membership on a staging copy and verify that child accounts lose access.
8. Restore the parent and confirm that older child accounts do not reconnect automatically without a new invitation.

Checking email and logs

Review email separately. A test send from Email Templates is useful for layout, but the real post-checkout email is a better test of whether variables are working properly. If your site has an email log, inspect the actual messages: is the group info present, is the link correct, and did the message end up looking suspiciously spammy because of an overly long or awkward subject line?

For sites with paid parent levels, also review orders and subscriptions. Make sure child members are not creating separate payments and are not receiving access through the wrong pricing path. If you are using per-seat pricing, compare the selected seat count with the test charge and the expected recurring billing model.

Limitations and Architectural Decisions Best Accepted Early

Group Accounts is flexible, but it should not be treated as a replacement for a CRM, LMS reporting layer, or a complex role system. The earlier you separate what the plugin actually does from what needs to be handled by other tools, the fewer false expectations you will create for customers and support staff.

The parent manages only the next level down

In a three-level structure such as "grandparent - parent - child," each level manages only the level directly below it. A grandparent can sponsor parent accounts, and parent accounts can sponsor child accounts, but the grandparent does not gain direct control over the final child accounts. If your client needs one top-level administrator who can see everyone across all divisions, you will need separate reporting, backend workflows, or a more specialized system.

The group code zeroes out the child access price

The three-level documentation explains that group codes effectively reduce the price to zero for sponsored levels. That makes sense in a model where the upper level pays. But if you want each lower level to pay part of the cost, the standard code logic may not fit. In that case, it is usually better to redesign your levels and pricing than to force one group code to play two conflicting roles.

Admin seat changes and billing

Manually changing the number of seats in a group is not the same as automatically changing the subscription. That distinction should be documented in your support workflow. If a customer asks to add 10 employees, the operator needs to know whether billing changes, whether a new order is required, whether simply increasing the seats is enough, or whether a different level is needed. Without that procedure, the site may technically allow more members while the commercial record falls out of sync.

Page builders and shortcode behavior

The Manage Group page is built around a shortcode. If you are using a page builder, do not turn that system page into a complex layout with nested dynamic blocks before the base functionality has been tested. Start by validating the shortcode on a plain page. If everything works, then add presentation around it carefully. There are open GitHub discussions related to editing the Manage Group page in Elementor, so with a nonstandard editor it is safest to keep the system page as simple as possible.

When Paid Memberships Pro Group Accounts Is the Right Choice

Paid Memberships Pro Group Accounts is worth using when your site already runs on PMPro and you need a true group model: one owner, seat limits, child accounts, invitations, a group code, an admin table, and a clear connection between the parent's payment and the members' access. The product is especially strong for corporate training, associations, educational programs, family memberships, and teams where each participant needs to keep an individual account.

Before launch, verify more than just the presence of the plugin. Review the level architecture, the Manage Group page, email, caching, test checkout, cancellation behavior on the parent account, and import workflows if you are migrating existing users. When those pieces are put together carefully, group accounts stop being just an extra feature and become a manageable product offer for organizations and teams.

If this model fits your site after reading the guide, you can move to the download section and download the ZIP file, then test it on a staging copy using the checklist above. That is much safer than enabling group levels immediately on a live pricing page.

If, instead, you only need individual access, a complex LMS hierarchy, WooCommerce-style store logic, or a corporate portal with department-level reporting, compare the architecture first. The right choice here is not about how many features a product has. It is about how naturally it fits the way you sell, invite, and support members.