Native Payments & Billing

If you sell memberships, subscriptions, or premium access, payments are never just about taking money. You also need the billing layer to connect cleanly to the member experience. That is what the Payments module in BricksMembers is designed to solve.

BricksMembers already has a powerful Webhooks system, and that remains a great option when you want to connect almost any payment provider, especially external systems that do not live on the same WordPress site. Webhooks are flexible and often a very sensible architecture because checkout, billing, and account management can stay separated from the membership website.

But that flexibility also comes with a tradeoff: the customer experience is usually less native. In many webhook-based setups, users buy on one system, manage billing somewhere else, and leave your site whenever they want to view subscription details, invoices, or payment settings. The Payments module is for the case where you want billing to feel much more integrated into the BricksMembers experience itself. It can even be useful together with webhooks though. More about that further below.

The Payments module gives BricksMembers a provider-neutral billing layer. You can sell memberships through native providers like Stripe, PayPal, and Square, sync billing data from WooCommerce, FluentCart, and SureCart, or map external systems through webhooks. All of that feeds into one shared billing model that works with Bricks elements, dynamic tags, conditions, and member-facing account screens, so you can build a setup where users rarely need to leave your website at all.

Why the Payments Module Matters

Most WordPress membership sites end up with fragmented billing. Checkout happens in one place, subscriptions live somewhere else, invoices are hard to expose, and the member dashboard has no clean way to reflect what the customer actually bought. Customers end up bouncing between systems, and site owners end up building frontend workarounds just to show basic billing information properly.

The Payments module closes that gap. It gives you a consistent billing layer for offers, subscriptions, payments, actions, and frontend display, so your sales flow and your member area finally speak the same language.

If your goal is that customers can buy, log in, view plan data, see payment history, and trigger billing actions without bouncing between multiple systems, Payments is the better fit. If your goal is mainly broad provider compatibility or an external checkout architecture, the general Webhooks module can still be the better choice.

What You Can Do With the BricksMembers Payments Module

• Sell membership offers with one-time or recurring billing models (subscriptions)
• Use native checkout through Stripe, PayPal, or Square directly from Bricks
• Sync billing data from your store when you already sell through WooCommerce, FluentCart, or SureCart
• Map external providers through webhooks if your checkout happens outside WordPress
• Show subscription and payment data in Bricks with dynamic tags, conditions, and query loops
• Give members self-service actions such as manage billing, cancel subscription, or refresh subscription state

How Payments Works in BricksMembers

The overall setup is straightforward:

1. Enable the Payments module
2. Decide whether you want native checkout, commerce sync, webhook billing, or a combination
3. Create billing offers and map them to your membership levels
4. Add the billing elements and dynamic data to your Bricks pages

Once that is in place, BricksMembers can use the same billing data across checkout, account pages, loops, and frontend conditions.

Step 1: Enable the Payments Module

1. Go to BricksMembers → Settings → Modules
2. Enable Payments
3. Save settings
4. Open the new Payments area in BricksMembers

After enabling the module, you will see billing-related pages for providers, offers, subscriptions, payments, and events.

Step 2: Choose Your Checkout and Billing Source

You do not need to use Payments in only one way. The module supports three practical paths, depending on how your business already works.

• Native checkout inside BricksMembers if you want Stripe, PayPal, or Square checkout directly from your Bricks pages
• Commerce sync if you already sell through WooCommerce, FluentCart, or SureCart and want the billing data available in BricksMembers
• Webhook billing sync if your checkout happens through an external platform and you want that data mapped into BRM billing. That only works with data your provider exposes.

This is one of the strongest parts of the Payments module. It is not locked to a single checkout philosophy. You can choose the path that matches your current stack instead of rebuilding your business around the plugin.

If you are comparing this with the general Webhooks module, think about it this way: use Webhooks when your checkout or billing system already lives elsewhere and you mainly need BRM to react to purchase events. Use Payments when you want the billing layer itself to feel integrated into your BRM and Bricks frontend, including account views, billing actions, loops, tags, and a more on-site customer experience.

Step 3: Configure Native Providers If You Need Them

If you want BRM to start hosted checkout sessions directly, configure the providers you plan to use. The native provider pages are not just credential screens. Each one has a real setup flow.

1. Go to BricksMembers → Payments → Stripe, PayPal, or Square
2. Run the provider setup assistant and complete Step 1: Connect by entering the provider credentials and testing the connection
3. Complete Step 2: Webhook by registering the BRM billing webhook URL in the provider dashboard and saving the provider-specific verification value in BRM, such as the Stripe signing secret, PayPal webhook ID, or Square webhook signature key
4. After that, use Step 3: Map Offers to connect real provider catalog items to your BRM offers

That last step is critical. Native checkout is not complete just because the API keys work. BRM also needs to know which Stripe price, PayPal plan, or Square variation belongs to which BRM offer. The Payments Module makes that easier compared to the webhook system though as it connects via API to fetch the products, variations and prices directly.

If you sell only through WooCommerce, FluentCart, or SureCart, you can skip the native provider setup pages. Billing sync will still work as long as the relevant commerce module and Payments are enabled.

Step 4: Create Billing Offers

Offers are the central link between billing and access. They define what you are selling and which membership levels that purchase should represent inside BricksMembers.

1. Go to BricksMembers → Payments → Offers
2. Create a new offer
3. Set the offer key, label, and billing model
4. Set the billing details, including billing model, price amount where relevant, currency, and which BRM membership levels the offer should grant
5. Choose which native checkout providers this offer should support and whether BRM should use a default provider automatically or let the customer choose
6. Save the offer

Create the BRM offer first. The offer is your internal billing blueprint inside BricksMembers. It defines what the customer is buying in BRM terms. The provider pages connect that BRM offer to a real provider item afterward.

Step 5: Connect Each Offer To Real Provider Items

After your offers exist, go back to the provider page and open Map Offers. This is where native checkout becomes fully wired up.

• Stripe recurring offers connect to a real Stripe Price
• Stripe one-time offers connect to a real Stripe One-Time Price
• PayPal recurring offers connect to a real PayPal Plan
• PayPal one-time offers use the provider-side one-time checkout option for that offer
• Square recurring offers connect to a real Square Plan Variation
• Square one-time offers connect to a real Square Catalog Item Variation

In the current BRM admin flow, you do not type those IDs by hand. BRM fetches the provider catalog from the connected account and lets you choose the real provider item from a dropdown. So the full flow is: connect provider, register webhook, create offer, then connect that offer to the correct provider item from the live provider catalog.

If you already use WooCommerce, FluentCart, or SureCart, the existing product-to-level mappings in those integrations can resolve into offers when the Payments module is active. For external webhook-based billing, go to BricksMembers → Webhook Mapping and use the Billing Sync card. That screen does not map a whole external product catalog. Instead, it lets you enable billing sync, choose one BRM offer, and map the incoming billing fields BRM needs, such as event type, customer email, external subscription ID, status, amount, currency, and manage URL.

Adding Checkout to Your Bricks Pages

The BRM Checkout element is the frontend entry point for native checkout. Add it to your pricing page, sales page, or offer comparison layout in Bricks.

• Select the billing offer you want the element to sell
• Choose Auto if the offer decides the provider automatically
• Choose User Choice if you want the customer to pick Stripe, PayPal, or Square
• Style the element as a button or link to match the page design

If the element is placed inside a BRM Billing Offers query loop, you can use the current loop item as the offer source so each offer renders its own checkout control automatically.

If no eligible native provider is available for the chosen offer, the checkout element does not disappear silently. It stays visible and shows Checkout is currently unavailable. That usually means the offer does not have an active provider mapping yet or the provider has not been configured completely. Technical checkout errors are kept in server logs instead of being exposed to visitors.

Let Members Manage Their Billing

The BRM Billing Action element is for logged-in customer self-service. It lets members interact with their subscription without leaving the experience feeling disconnected from the rest of the site.

• Manage Billing sends the user to the provider billing portal or another resolved manage URL
• Cancel Subscription lets the user cancel through BRM where supported
• Refresh Subscription resyncs the latest subscription state from the provider

If the element sits inside a BRM User Subscriptions query loop, set the target subscription to the current loop item so each row gets its own action button.

For integrated commerce sources, you can use the brm_payments_resolve_manage_url filter to return your WooCommerce My Account subscriptions URL or a similar destination for the manage action.

Be concrete about the action support you expect. Native providers like Stripe, PayPal, and Square can expose manage, cancel, and refresh flows through BRM. Integrated commerce sources like WooCommerce, FluentCart, and SureCart are usually manage-and-refresh surfaces, not direct BRM cancellation surfaces, so the practical setup there is normally a manage link into the commerce system plus refresh.

Billing Data You Can Show in Bricks

One of the most practical benefits of the Payments module is that billing data becomes available as frontend content. You can use billing dynamic tags anywhere Bricks accepts text output, but it is important to understand exactly which subscription or loop item the tag is reading from.

Outside query loops, the main {brm_billing:*} tags resolve in this order: the current loop subscription if you are already inside a subscription loop, otherwise a single actionable subscription if the user has exactly one actionable subscription, otherwise the current active subscription, otherwise the latest subscription row for that user. If there is no logged-in user or no matching subscription, the tags return empty strings, except {brm_billing:cancel_at_period_end}, which returns 0.

Subscription Tags

• {brm_billing:status} returns the raw status slug, such as active, trialing, past_due, paused, cancelled, expired, pending, paid, failed, or refunded
• {brm_billing:provider} returns the raw provider key, for example stripe, paypal, square, woocommerce, fluentcart, surecart, or generic_webhook
• {brm_billing:offer_key} returns the stored offer key slug, such as premium-monthly
• {brm_billing:offer_label} returns the human label from the BRM offer config. If the offer config no longer exists, it falls back to the stored offer key
• {brm_billing:period_start}, {brm_billing:period_end}, and {brm_billing:trial_ends_at} return dates formatted with the site’s WordPress date format, for example March 25, 2026. If the stored date is empty, the tag outputs an empty string
• {brm_billing:cancel_at_period_end} returns 1 when the subscription is marked to end at the current period boundary and 0 otherwise
• {brm_billing:manage_url} returns the validated manage-billing URL for the resolved subscription, or an empty string if there is no safe manage URL available
• {brm_billing:last_amount} returns a formatted amount like $29.00. The current runtime always formats that display value with a dollar-sign style prefix, so use {brm_billing:last_currency} beside it when you need the exact currency code shown too
• {brm_billing:last_currency} returns the uppercased currency code, such as USD, EUR, or JPY
• {brm_billing:last_payment_at} returns the last payment date formatted with the site’s WordPress date format, or an empty string if there is no recorded payment date yet

Loop Item Tags

The loop tags are more powerful, but they are also more context-sensitive. The exact output depends on which BRM billing query loop you are inside.

Inside a BRM Billing Offers loop: {brm_billing:item:offer_key}, {brm_billing:item:offer_label}, {brm_billing:item:description}, and {brm_billing:item:billing_model} return offer blueprint data. {brm_billing:item:checkout_providers} returns the enabled native checkout providers as human labels joined by commas, such as Stripe, PayPal. {brm_billing:item:default_provider} returns the human label of the default native provider, such as Stripe. In this context, billing-state fields like status, provider, period_start, period_end, amount, currency, paid_at, and status_badge are empty, and {brm_billing:item:cancel_at_period_end} returns 0.

Inside a BRM User Subscriptions loop: {brm_billing:item:status}, {brm_billing:item:provider}, {brm_billing:item:offer_key}, {brm_billing:item:offer_label}, {brm_billing:item:period_start}, {brm_billing:item:period_end}, and {brm_billing:item:cancel_at_period_end} read from the current subscription row. In this context, {brm_billing:item:amount}, {brm_billing:item:currency}, and {brm_billing:item:paid_at} come from the last payment attached to that subscription.

Inside a BRM User Payments loop: {brm_billing:item:amount}, {brm_billing:item:currency}, and {brm_billing:item:paid_at} come from the current payment row itself. {brm_billing:item:status_badge} outputs an HTML badge span such as <span class="brm-billing-badge brm-billing-badge--paid">Paid</span>, so use it only in elements that are allowed to render HTML. In the current runtime, this payments loop is built from payments attached to subscription rows. Standalone one-time payment rows are not currently exposed through the BRM User Payments query.

That combination is what makes it possible to build account pages that show active subscriptions, recent payments, upcoming renewals, offer metadata, and billing history without custom PHP.

Billing Conditions You Can Use in Bricks

Bricks conditions can react to billing state too. Here is what each billing condition actually checks in the current runtime.

• BricksMembers: Has Active Subscription checks whether the logged-in user has an active or trialing subscription. Logged-out visitors count as “no”
• BricksMembers: Subscription Status compares against the resolved subscription status slug, such as active, trialing, past_due, or cancelled
• BricksMembers: Has Offer checks whether the user currently has an active or trialing subscription for a specific offer key
• BricksMembers: Billing Provider compares against the resolved subscription provider, for example stripe, woocommerce, or surecart
• Current loop subscription supports action only works inside a subscriptions loop and checks whether the current row supports manage_billing, cancel, or refresh
• User has multiple actionable subscriptions and User has one actionable subscription use the actionable statuses active, trialing, past_due, and paused

Using Payments With WooCommerce, FluentCart, and SureCart

If you already have a working store, this is where the Payments module becomes especially useful. You do not need to rebuild everything around native checkout just to get billing-aware frontend surfaces in BricksMembers.

When both the Payments module and one of the supported commerce integrations are enabled, BricksMembers syncs subscription data into its billing tables. That powers billing dynamic tags, billing conditions, billing actions where supported, and the subscription/payment query loops.

Catalog matching follows the same identifiers you configure in the commerce integrations. WooCommerce can match parent products and specific variations, FluentCart can match products and variations, and SureCart can match products, prices, and variants. If one catalog entry has multiple plan options, map the exact variation, price, or variant you want BricksMembers to recognize.

Level assignment still belongs to the commerce integration itself. Payments sync is there to make the billing data usable in the member experience. It is not a second access-assignment system layered on top.

Common Use Cases

• Membership pricing pages built in Bricks with checkout buttons for each offer
• Customer account areas that show plan name, renewal date, payment history, and manage billing actions
• Commerce-powered membership sites where WooCommerce, FluentCart, or SureCart handles checkout but BRM still powers the member dashboard
• External billing stacks that send purchase data into BricksMembers through webhooks
• Bricks condition-based upsells that show different content depending on subscription state