Gift Memberships and Transfers

Gift memberships sound simple on the surface. One person pays, someone else should get the access. In practice, that can become messy very quickly if checkout, billing, account creation, and membership levels all live in different places.

That is why BricksMembers now has a dedicated Gifting feature. It gives you one clear place to control how gifts work, and it supports both native BRM checkout gifting and post-purchase membership transfers for store-based setups like WooCommerce, SureCart, and FluentCart.

The important part is that you do not have to force every site into the same workflow. Some sites want full native gift checkout. Others already sell through a store and simply need an easy way for the buyer to transfer a purchased membership to someone else later. BricksMembers supports both.

What Gift Memberships Mean in BricksMembers

In BRM, gifting can happen in two practical ways:

• Native gift checkout, where the buyer chooses gift details during a BRM Payments checkout
• Post-purchase transfer, where the buyer purchases normally first and then transfers the membership level to another user afterward

That second option is especially useful when your checkout already lives in WooCommerce, SureCart, or FluentCart. You do not need to rebuild the whole store experience just to support gifting.

The Two Gifting Modes

The Gifting page gives you one key switch that changes how much infrastructure BRM should use:

• Lightweight transfer mode works when Gifting is enabled but Enable Subscription & History is turned off. In this mode, one-time transfers still work, but BRM does not create the shared gift records table.
• Subscription & History mode turns on the shared gift records table. Use this when you want native Payments gifting, stored gift history, or subscription-based gift transfers.

If you also enable Payments, BRM automatically requires Enable Subscription & History because native gift checkout depends on the shared gift records table.

Where to Turn It On

1. Go to BricksMembers → Modules and enable Gifting.
2. Open BricksMembers → Gifting.
3. Decide whether you want lightweight one-time transfers only, or whether you also want subscriptions and stored gift history.
4. Choose whether BRM should Create recipient users automatically.
5. Choose the Default role for new recipient users if BRM needs to create an account during a gift flow.

That page is also where admins can review stored gift and transfer records once subscription and history mode is enabled.

How Native Payments Gifting Works

If you use the BRM Payments module, you can offer true gift checkout directly on your Bricks pages.

1. Enable both Gifting and Payments.
2. Open BricksMembers → Payments and turn on Enable native gift checkout for supported Payments offers.
3. In BricksMembers → Payments → Offers, open the offer you want to sell and enable gifting for that offer.
4. For new pages, add BRM Checkout Context to a Bricks page and place BRM Checkout Gift Fields, BRM Checkout Payment Form, and BRM Checkout Trigger inside it. Existing pages can still use BRM Checkout (Legacy).

Once that is done, the checkout can show gift fields such as recipient email and, if allowed, an optional message. After payment succeeds, BRM creates the gift record, sends the claim email, and holds the gifted access for the recipient instead of silently granting it to the purchaser.

Public claim landing templates can use the gift claim dynamic tags added in 0.9.94: {brm_gift:sender_name}, {brm_gift:offer_title}, {brm_gift:message}, {brm_gift:expires_at}, {brm_gift:status_label}, and {brm_gift:claim_url}. Claim result pages can use {brm_gift:claim_message} for the human-readable success or error state.

Transfer pages can use {brm_gift_transfer:*} tags when the page URL includes brm_gift_source, brm_gift_object_type, and brm_gift_object_id. Use {brm_gift_transfer:title} and {brm_gift_transfer:amount} for the displayed source object, and pass {brm_gift_transfer:source}, {brm_gift_transfer:object_type}, and {brm_gift_transfer:object_id} into the hidden Bricks form fields for brm_transfer_gift_level.

Recurring gift checkout is currently the strictest path. It is meant for cases where you want the cleaner native billing experience and reliable recurring lifecycle handling inside BRM itself.

How Store-Based Gift Transfers Work

If you already sell through WooCommerce, SureCart, or FluentCart, the gifting flow is intentionally simpler.

1. The customer buys the membership normally through the existing store flow.
2. BRM grants the mapped membership level to the purchaser as usual.
3. Later, the purchaser uses a frontend form to transfer that level to another email address.
4. BRM creates or finds the recipient account, assigns the level to the recipient, and removes that same level from the current owner.

This keeps the store integration compatible with the normal purchase flow while still giving site owners a clear way to support gift memberships.

When Enable Subscription & History is off, this direct transfer flow is meant for one-time purchases only. When you turn that setting on, BRM can also store transfer history and support subscription-based gift transfers through the shared gift records table.

Building the Frontend in Bricks

There are two main frontend building blocks:

• BRM Checkout Context plus its gift/payment child elements for native Payments gifting
• Transfer Gift Level (BRM) as a Bricks Form action for post-purchase transfers

For the transfer form, BRM expects the source context to be passed into the form, typically with hidden fields such as:

• source
• object_type
• object_id
• recipient_email

You can also collect recipient first and last name if you want BRM to use them when it creates a new account.

This is a good example of why Bricks integration matters here. You are not locked into a hardcoded gift screen. You can build the transfer page in the same visual system as the rest of your member experience.

What Members Receive by Email

Email behavior depends on the flow:

• Native Payments gifting sends a claim email to the recipient after payment succeeds.
• If the recipient does not already have a WordPress account and you allow BRM to create one automatically, BRM also sends the standard WordPress new-user email for that account.
• Store-based transfer gifting does not run a separate branded claim flow. It simply transfers the level and, when needed, creates the user account.

That means your email setup still matters. If you want those core WordPress account emails to feel branded and polished, the Emails module is still worth configuring.

When to Use Which Setup

• Use native Payments gifting when you want the cleanest checkout and claim experience directly on your BRM site.
• Use post-purchase transfers when you already sell through WooCommerce, SureCart, or FluentCart and want gifting without rebuilding checkout.
• Turn on Enable Subscription & History when you want stored gift records, admin history, or subscription-based gifting behavior.

The big advantage of the new BRM gifting architecture is that it lets you choose the lighter or richer path without having to switch membership plugins or bolt on a second system.

If you already use the Payments module, gifting can become a natural part of the same billing experience. If you already use a store, gifting can stay simple and practical. Either way, BRM now gives you a real gifting workflow instead of forcing you to fake it with manual admin work.