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 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.

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: 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.
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 auto-creation still needs 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 and product value.

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, and optional variation value.
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.

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.
Enable the rule.

In the current BricksMembers group flow, 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.

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 manually create the group after checkout. BricksMembers creates it from the matched seat rule, sets the buyer as the owner, applies the configured member-seat count, and lets the owner manage invitations from the group dashboard. A retried webhook or repeated payment event should not create another group for the same purchase reference.

The initial group name is only a safe default. If the purchase flow does not pass a custom 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”. That keeps the 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 Template Assistant’s Group Dashboard and Group Seat Meter templates include 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.
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. Generic webhook sources do, because BricksMembers needs to know where the buyer email, successful event value, product value, and optional variation value 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 the BricksMembers checkout element or checkout URL for the offer.
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 Template Assistant 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.
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, 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}, 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), and optionally let them create reusable join links with Create Group Join Link (BRM). Those frontend group actions should all point at the same current group ID.

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 -> Settings -> General 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}}.

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.
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 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.