How to sell group licenses

This guide shows how to sell individual and group licenses with BricksMembers no matter where checkout happens. It covers native Payments providers, same-site commerce plugins, and external systems that send provider webhooks.

The goal is the same in every setup: a single-license buyer gets access for their own account, while a group-license buyer becomes the group owner and can invite members into the member seats they purchased.

Updated in version 1.1.0: group-license setup now uses selectable purchase sources for native Payments, WooCommerce, FluentCart, and SureCart seat rules, records purchased team seats in seat pools, lets owners allocate seats between their own groups from the frontend, can collect a checkout group name through Member Profile fields, adds automatic group-name prefix/suffix settings, lets owners or leaders rename their group from the frontend, and keeps global invite defaults under BricksMembers -> Groups -> Settings.

The Short Version

There are three jobs to configure:

Checkout and access: the product, plan, offer, or webhook value grants the buyer the right BricksMembers level.
Group creation and seat pool: the successful purchase source matches a Groups seat rule. Native Payments uses the BRM offer, WooCommerce, FluentCart, and SureCart use their connected product/source IDs, and generic webhooks use the mapped product value from the payload. BricksMembers records the purchased team seats, creates or tops up the buyer’s group according to the rule, and prevents duplicate payment/webhook retries from granting seats twice.
Emails: Automations and Emails send welcome, invitation, payment, and cancellation messages.

Do not skip the second job for group licenses. A product-to-level mapping can grant access, but group creation and purchased-seat tracking still need a matching Groups seat rule. Native Payments, WooCommerce, FluentCart, and SureCart can match the purchased offer or connected product directly. Only generic webhook sources need manual payload mapping for the successful purchase signal, product value, variation value, and quantity.

Choose Your Selling Source

Pick the path that matches how you sell today.

Native Payments: use BricksMembers checkout with Stripe, PayPal, or Square. This is the cleanest path when you want BRM offers, checkout buttons, billing screens, billing tags, and billing automations in one place.
WooCommerce, FluentCart, or SureCart: use the store checkout and map store products to BricksMembers levels under Integrations. If Payments is also enabled, BricksMembers can sync billing data from those integrations for billing displays and billing automation triggers.
Generic webhooks: use this when checkout is somewhere else, or when you want an external system to create users, grant or remove access, and optionally send billing data into BricksMembers.

Before You Start

Create the access levels you need, such as Pro Member, Team Owner, and Team Member.
Enable Groups, Emails, and Automations in BricksMembers -> Modules.
Enable Payments if you use native Stripe, PayPal, or Square checkout, or if you want billing sync from WooCommerce, FluentCart, SureCart, or generic webhooks.
Decide where buyers go after checkout, where group owners manage members, and where invited members land after accepting an invite.
Brand your WordPress account emails in BricksMembers -> Emails -> WordPress Emails, especially New User (to user) and Password Reset.

Step 1: Create the Products or Plans

Create one sellable item for each plan. Use clear names because you will map the same items back to BricksMembers.

Native Stripe: create Stripe Prices for each recurring or one-time plan.
Native PayPal: create PayPal billing plans for subscriptions. PayPal one-time checkout uses the BricksMembers offer price directly, so no PayPal plan ID is needed for one-time offers.
Native Square: create Square subscription plan variations for recurring plans and catalog item variations for one-time products.
WooCommerce, FluentCart, and SureCart: create the store products, variations, prices, or purchases you want customers to buy.
Generic webhooks: make sure the checkout payload contains a stable product, price, plan, or SKU value that BricksMembers can read.

Step 2: Configure Buyer Access

Native Payments

Go to BricksMembers -> Payments.
Enable and connect Stripe, PayPal, or Square.
Register the provider’s BricksMembers billing webhook URL and save the required webhook secret or webhook ID.
Create one BricksMembers offer for each plan you sell.
Choose the billing model, granted levels, checkout provider, and provider mapping for that offer.

The provider mapping fields pull live catalog options from the connected provider account, so you are not expected to copy native provider IDs by hand. Stripe offers let you pick a Stripe Price. PayPal subscriptions let you pick a PayPal billing plan, while PayPal one-time checkout uses the offer price directly. Square recurring offers let you pick a subscription plan variation, and Square one-time offers let you pick a catalog variation.

WooCommerce, FluentCart, and SureCart

Go to BricksMembers -> Integrations.
Open the WooCommerce, FluentCart, or SureCart tab.
Map each store product, variation, or source item to the BricksMembers levels it should grant.
Enable guest-user creation if buyers may check out without an existing WordPress account.
Choose the refund, cancellation, expiration, and hold/removal settings that match your access policy.

For a group plan, map the store product to the buyer’s owner level, such as Team Owner. The seat rule later handles the group and the member levels.

Generic Webhooks

Go to BricksMembers -> Integrations -> Webhook Mapping.
Choose the provider preset when one fits, or switch to advanced mode for a custom payload.
Send a real test webhook first, then use the Last Received Webhook Data sidebar to map fields accurately.
Map the buyer email, the event key, add-event values, remove-event values, product value, optional variation value, and optional purchase quantity.
Enable user creation if the webhook should create new WordPress users.
Map product values to levels for single-license access and group-owner access.

If Payments is active and you want billing records from a generic webhook source, also configure the billing field mapping for the same webhook profile. Generic billing webhooks support normalized events such as subscription_created, subscription_updated, subscription_cancelled, payment_succeeded, payment_failed, and payment_refunded.

The product, variation, and quantity field mappings in Webhook Mapping are for generic webhook payloads only. Native Payments, WooCommerce, FluentCart, and SureCart send their product/source and quantity data through their own integration paths.

Step 3: Set Up Group Seat Rules

Seat rules are what turn a group-license purchase into a real BricksMembers group.

Go to BricksMembers -> Groups -> Seat Rules.
Create one seat rule for each group plan.
Choose the purchased source for the group plan. For native Payments, select the BRM offer. For WooCommerce, FluentCart, or SureCart, select the product, variation, price, or source item from the connected plugin. Choose the custom webhook option only when the source is a generic webhook payload.
Set Total Seats to the number of non-owner member seats included in the plan.
Set the default levels granted through the group, such as Team Member.
Choose Seat fulfillment. The default creates a new group for each purchase. The primary-group options still make sure the buyer has a group, then add later purchases to the buyer’s primary group so seats can be moved later from the dashboard.
Optionally use Automatic Group Names on the same screen to add a prefix or suffix to purchase-created group names.
Enable the rule.

The purchaser is added as the group owner and does not consume one of the limited member seats. If you sell “owner plus 5 invited members”, set Total Seats to 5. If your sales copy says “5 people total including the owner”, set Total Seats to 4 or change the copy to say “5 member seats plus owner”.

The default levels on the seat rule are granted to people added to the group, including the owner created with the group. Use the checkout access mapping for any extra owner-only access.

When the same customer buys multiple quantities or buys again later, BricksMembers adds those purchased seats to the buyer’s seat pool for that seat rule. Owners can then create another group from the pool or adjust seat allocations between their own groups. A group cannot be reduced below the seats already used by active members plus seats reserved by pending email invitations.

Step 4: Confirm the Purchase Signal for Group Creation

This is the part that makes the guide work across all providers. The group is created when BricksMembers resolves the buyer, reads the purchased source, and finds a matching seat rule.

The buyer does not need to manually create their first group after checkout. BricksMembers records the purchased seats, creates or tops up a group from the matched seat rule, sets the buyer as the owner, applies the configured member-seat count, and lets the owner manage invitations and later seat allocation from the group dashboard. A retried webhook or repeated payment event should not create another entitlement for the same purchase reference.

For native Payments checkout, you can ask the buyer for the group name before payment. Add BRM Checkout Fields inside the checkout context and enable the group/team name field. When the checkout completes and a matching seat rule creates the group, BricksMembers uses that sanitized value as the initial group name. Existing setups that use a checkout-enabled Member Profile text field mapped to Group name still work as a fallback.

The generated initial group name is still the safe fallback. If the purchase flow does not pass a checkout group name, BricksMembers uses the buyer’s display name and the configured group type label, for example “Dana Buyer’s Team” or “Dana Buyer’s Client Team”. If you configured an automatic prefix or suffix in Groups -> Seat Rules, that text is added around the generated name. That keeps checkout automatic, but it should not be treated as the final company, cohort, or team name.

Give owners a way to rename the group after checkout. The BricksMembers Assistant’s Templates mode includes Group Dashboard and Group Seat Meter templates with a native Bricks form for this. If you build the page manually, add a text field such as group_name, a hidden field or static setting for the current {brm_group:id}, and the Bricks Form action Update Group Profile (BRM). The action updates the group through BricksMembers, and it only works for logged-in users who can manage that group. Site admins can also rename a group from BricksMembers -> Groups.

Native Payments: create the BRM offer, connect it to Stripe, PayPal, or Square, then use that same BRM offer in the seat rule.
WooCommerce, FluentCart, and SureCart: map the store product/source to the buyer’s owner level in BricksMembers -> Integrations, then use that same product/source in the seat rule.
Generic webhooks: open BricksMembers -> Integrations -> Webhook Mapping, send a real test event, and load it into the mapping UI.
For generic webhooks, map the buyer email to the customer email field.
For generic webhooks, map the event key and add-event values so only successful purchases create groups.
For generic webhooks, map the product value to the same raw value you entered after choosing the custom webhook option on the seat rule.
For generic webhooks, map the purchase quantity if one checkout event can represent more than one team-license quantity. If you leave it empty, BricksMembers treats the purchase as quantity 1.
Send a test purchase and confirm the buyer gets access and the group is created.

Native Payments and the same-site WooCommerce, FluentCart, and SureCart integrations do not need a separate generic webhook mapping just to create the group or read quantity. Generic webhook sources do, because BricksMembers needs to know where the buyer email, successful event value, product value, optional variation value, and optional quantity live in the incoming payload.

Step 5: Build the Buying and Group Pages

Your pricing page should make the license model obvious. For group offers, say “5 member seats plus owner” when the owner does not count against the member-seat limit.

Native Payments: use an atomic checkout page built with BRM Checkout Context and its checkout child elements. Include BRM Checkout Fields when the checkout should collect buyer, billing, tax, group-name, or optional checkout-enabled profile fields.
WooCommerce, FluentCart, and SureCart: link to the store product checkout.
Generic webhook sources: link to the external checkout and make sure it sends a completed-purchase webhook back to BricksMembers.

You do not have to build every page from scratch. Open the BricksMembers Assistant’s Templates mode and start from the closest template:

Public Membership Landing or Pricing & Offers for the sales and pricing page.
Checkout for native Payments checkout pages.
Account Home, Account Settings, Billing & Account, Invoices, or Member Dashboard for member account pages.
Group Dashboard for the owner page where customers manage members and invitations.
Group Invite Join Claim for the page invited people use when they accept an invitation.
Group Invite Form, Group Seat Meter, Group Member Row, and Join Link Panel when you only need individual group-management sections.
Group Seat Allocation Panel when owners should create additional groups from purchased seats or change a group’s allocation.
Login / Register Hub and Access Denied / Upgrade for the supporting auth and upgrade pages.

On the group owner page, owners should be able to view the group name, used seats, available seats, occupied seats, movable seats, members, pending invitations, and invitation controls. Useful dynamic tags include {brm_group:name}, {brm_group:total_seats}, {brm_group:used_seats}, {brm_group:available_seats}, {brm_group:occupied_seats}, {brm_group:movable_seats}, and {brm_group:pending_invite_count}.

The practical owner dashboard flow is: show the current name with {brm_group:name}, let the owner or leader rename it with Update Group Profile (BRM), let them invite people with Invite Group Member by Email (BRM), optionally let them create reusable join links with Create Group Join Link (BRM), and let owners allocate purchased seats with Create Group From Seat Pool (BRM) and Update Group Seat Allocation (BRM). The separate Move Group Seats (BRM) action is available for custom source/target forms, but the starter templates avoid raw group-ID fields. Invitation and rename actions can be used by owners or leaders when allowed; seat allocation is owner-only.

Email invitations reserve a member seat while pending. Join links do not reserve a member seat; they only work if a member seat is still available when the person uses the link.

Step 6: Configure Invitation Redirects

Go to BricksMembers -> Groups -> Settings and choose the pages used by group invitations.

Guest redirect page: where invited people go if they need to log in or register first.
Post-claim redirect page: where people go after the invite is accepted.
Invite feedback: choose whether to show BricksMembers success and error notices or build your own message on the redirect page.

If you build your own feedback message, the invite state tags are {brm_group:invite_claim_state}, {brm_group:invite_claim_error}, and {brm_group:invite_claim_message}.

Step 7: Build the Email Automations

The important part is not writing the email copy. The important part is triggering each email from the event that actually proves the customer, owner, or invitee reached that stage.

Start in BricksMembers -> Emails. Use Create From Starter for the standard messages, then adjust the copy, subject, and links for your site. BricksMembers includes starter templates for access welcomes, group owner welcomes, group invitations, invite-accepted messages, failed-payment notices, and access-changed notices.

Then go to BricksMembers -> Automations and create one workflow per trigger. Use the Send Email action, choose the matching email template, and keep the workflow active only after you have tested it.

Workflow 1: Buyer Access Welcome

Trigger: Membership Access Granted.
Action: Send Email.
Template: Membership Access Welcome.
Recipient: single recipient, using the default event user.
Timing: immediate.

This is the most provider-neutral welcome trigger because it fires after BricksMembers grants membership access. It works whether that access came from native Payments, WooCommerce, FluentCart, SureCart, or a mapped webhook.

Workflow 2: Group Owner Welcome

Trigger: Group Created.
Action: Send Email.
Template: Group Owner Welcome.
Recipient: single recipient, using the default event user.
Timing: immediate.

Use this workflow only for group plans. It should point owners to the Group Dashboard template page, explain the seat count, and remind them that pending email invitations reserve seats.

Workflow 3: Group Invitation

Trigger: Group Invitation Created.
Action: Send Email.
Template: Group Invitation.
Recipient: single recipient. The invitation event includes recipient_email, and BricksMembers uses that address when there is no WordPress user yet.
Timing: immediate.

This is the workflow where recipient setup matters most. Do not send invitation emails to the group owner. Use the invitation event and the invited address from the event context. Useful invitation placeholders include {{group_name}}, {{recipient_email}}, {{claim_url}}, {{inviter_name}}, {{invitation_role}}, {{group_available_seats}}, {{invite_email}}, {{group_invite_url}}, and {{group_role}}.

When this workflow is active, BricksMembers uses it for the first invitation delivery instead of also sending the old plaintext fallback email. Resending an invitation runs the same Group Invitation Created trigger again.

Workflow 4: Invite Accepted

Trigger: Group Invitation Claimed.
Action: Send Email.
Template: Group Invite Accepted.
Recipient: single recipient, using the default event user.
Timing: immediate.

Prefer Group Invitation Claimed for this message. Group Member Added also exists, but it can fire for other member-add moments, including the owner being added when the group is created.

Workflow 5: Failed Payment or Past Due Subscription

Trigger: Billing Payment Failed.
Second workflow: create another workflow for Billing Subscription Past Due if you want a separate past-due reminder.
Action: Send Email.
Template: Payment Failed or Past Due.
Recipient: single recipient, using the buyer or subscription owner from the billing event.
Timing: immediate for the first failed-payment notice, then delayed only if your dunning policy needs follow-up messages.

Use this when billing events are available from native Payments, cart billing sync, or generic billing webhooks. Keep the email focused on the billing page, not the sales page.

Workflow 6: Access Changed

Trigger: Membership Access Revoked.
Optional billing workflows: create separate workflows for Billing Subscription Cancelled and Billing Subscription Expired if those events matter for your provider setup.
Action: Send Email.
Template: Access Changed Notice.
Recipient: single recipient, using the default event user.
Timing: immediate.

Use the access trigger when you want the message tied to the actual access change. Use the billing triggers when you want a message tied to the subscription state itself.

Step 8: Test the Full Flow

Buy the individual product or offer in test mode, sandbox mode, or with a safe test product.
Confirm the buyer gets the expected level and receives the welcome email.
Buy the group product or offer.
Confirm the buyer gets owner access, the group exists, and Total Seats matches the non-owner member-seat count.
If the offer was bought with quantity greater than 1, confirm the group’s allocated seats match the quantity multiplied by the seat rule’s Total Seats.
As the owner, create a second group from the seat pool or adjust owned group allocations, then confirm BricksMembers blocks any change that would reduce a group below used plus reserved seats.
Send an email invitation from the group owner page.
Confirm the pending email invitation reserves one member seat.
Accept the invite as a new user and confirm the member joins the group, receives the group level, and lands on the right page.
Test a refund, failed payment, cancellation, or expiration and confirm access removal and emails match your policy.

Common Problems to Check

The buyer got access, but no group was created. The access mapping is working, but the seat rule is not matching the purchased source. For native Payments, check that the seat rule uses the BRM offer. For WooCommerce, FluentCart, or SureCart, check that it uses the connected product/source value. For generic webhooks, check the actual product value in the payload and make sure it exactly matches the seat rule.

The group was created with the wrong number of seats. Total Seats controls non-owner member seats. The owner is added separately and does not consume a limited member seat.

The owner has purchased seats, but the pool shows no available seats. That usually means the purchased seats are already allocated to an existing group. Use the allocation panel on a group with movable seats to create another group from that allocation or reduce that group’s total before increasing another owned group. BricksMembers will not let the owner move seats that are already occupied or reserved.

The provider item is missing from the native Payments offer picker. Confirm the provider module is enabled, credentials are saved, and the provider item is active in the connected Stripe, PayPal, or Square account.

A WooCommerce, FluentCart, or SureCart buyer did not get access. Check the product-to-level mapping, guest-user creation settings, order status, and whether the store plugin is active on the same WordPress site.

A webhook buyer did not get access. Check the Last Received Webhook Data, email field path, event key path, add-event value, and product value mapping.

An invitation says no seats are available. Look at used member seats and pending invitations. Pending email invitations reserve member seats until they are accepted, deleted, or expired.

A Good Default Setup

Start with one individual product and one team product. Map the individual product to Pro Member. Map the team product to Team Owner. Add a seat rule for the team product with Team Member as the default group level and the number of non-owner member seats you sell. Then create four emails first: access welcome, group owner welcome, group invitation, and payment failed or access revoked.

That gives you the full journey without overbuilding it: buy, get access, create a group, invite members, accept invitations, and handle payment or cancellation changes.