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 webhook field mapping 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, Bricks 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
Calculate taxes at checkout with Stripe Tax, manual rates, Avalara, or TaxJar, plus optional VAT/GST ID collection
Collect checkout customer details such as native WordPress buyer fields, company name, billing address, VAT/tax ID, group/team name, and optional Member Profile fields
Generate member invoices with downloadable PDFs, invoice templates, tax evidence, and Bricks invoice 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:

Enable the Payments module
Decide whether you want native checkout, commerce sync, webhook billing, or a combination
Create billing offers and map them to your membership levels
Configure taxes and invoice templates if your setup needs tax-aware checkout or customer invoice PDFs
Expose any supported Member Profile fields in checkout if you want to collect buyer details during purchase
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

Go to BricksMembers → Modules
Enable Payments
Confirm the change
Open BricksMembers → Payments

After enabling the module, you will see the Payments hub with sections for providers, offers, subscriptions, payments, taxes, invoices, and billing events.

Performance note: Payments stores billing records in dedicated indexed tables, and newer versions keep one-time payment offer keys in an indexed payment column for faster purchase checks and Bricks conditions. Older one-time payment rows are upgraded quietly in the background, so existing customers keep their access while future checks avoid slow JSON scans.

Upgrading from Members for Bricks Builder Free: If the old Free Stripe EasySync setup is detected, BricksMembers enables Payments and Stripe for that site and keeps the old EasySync webhook endpoint available. Open Payments -> Stripe after upgrading and review the setup summary before changing anything in Stripe. The compatibility bridge keeps existing one-time Price mappings working while you decide whether to move the site into full native Payments checkout. See Upgrading from Members for Bricks Builder Free.

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.

Go to BricksMembers → Payments and open the Stripe, PayPal, or Square provider section
Run the provider setup assistant and complete Step 1: Connect by entering the provider credentials and testing the connection
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
After that, use the provider’s Map Offers step 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.

Checkout Preview Mode: If you are still designing the page and have not connected Stripe, PayPal, or Square yet, enable Checkout Preview Mode in Payments settings. BRM will render the native provider choices in Bricks so you can finish the layout, but real checkout, embedded checkout, and PayPal confirmation remain blocked until provider credentials and offer mappings are actually configured.

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.

Go to BricksMembers → Payments and open the Offers section
Create a new offer
Set the offer key, label, and billing model
Set the billing details, including billing model, price amount where relevant, currency, and which BRM membership levels the offer should grant
Choose which native checkout providers this offer should support and whether BRM should use a default provider automatically or let the customer choose
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 relevant provider section 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 → Integrations → 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

For checkout pages, use the atomic checkout suite in the Bricks Members category. Start with BRM Checkout Context as the parent element, then place the checkout child elements inside it.

Choose how the checkout gets its offer: a specific offer, the current BRM Billing Offers loop item, a URL parameter, or all offers
Add the child elements you need inside the context, such as Provider Selector, Checkout Fields, Consent, Payment Form, Error Surface, and Trigger. Use Checkout Fields rows for profile fields and gift fields.
Use Embedded mode when you want Stripe or PayPal to stay on the page
Use Hosted Redirect when you want Stripe or Square to hand the customer off to a provider page. PayPal currently stays on the embedded flow.
Style the layout however you like, because provider choice, checkout fields, payment UI, consent, errors, and trigger are now separate elements instead of one locked widget

If the checkout context 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 automatically. If you want one reusable checkout page, use the URL-parameter offer source and the {brm_checkout:url_offer_key} tag to show the selected offer key in helper text or headings.

A common native checkout setup is a pricing page with a BRM Billing Offers loop and a checkout page with BRM Checkout Context. On the checkout page, set Offer Source to URL Parameter. The default parameter is offer, so pricing buttons can link to a URL such as /checkout/?offer=starter_monthly. In a billing-offers loop, use the current loop offer key in that URL, for example /checkout/?offer={brm_billing:item:offer_key}. If you change the BRM Checkout Context Offer URL Parameter setting, the pricing-page button URL must use the same parameter name.

Pricing cards can still be fully custom Bricks layouts. The safest pattern is to put the card design inside a BRM Billing Offers query loop so each card has the active offer context, then use /checkout/?offer={brm_billing:item:offer_key} on the button. If you keep three completely static cards instead, set each button URL manually to the matching offer key, such as /checkout/?offer=pro_monthly. There is no separate checkout URL tag that accepts an arbitrary offer ID outside an offer loop.

Currency is part of the BRM offer configuration, not only the provider dashboard. Set the offer’s base currency, manual multi-currency prices, and provider currency mappings in BricksMembers. The checkout currency selector and final checkout request use that BRM currency context; Stripe, PayPal, or Square then receive the resolved currency from BRM.

The immediate-access consent checkbox is controlled on the visible BRM Checkout Consent child element. Set the requirement there, edit the checkbox label, help text, missing-consent message, and the URL plus visible label for Terms, Privacy Policy, Withdrawal Information, and Withdrawal Form there. Leaving an individual legal URL empty omits that link. Setting the Consent element to Disabled / Hide Checkbox removes the required consent step completely. BRM signs the checkout intent after the visible Consent element settings are applied, so the stored consent proof matches the copy shown to the buyer.

Add BRM Checkout Fields inside the checkout context to collect checkout customer details. The element can render native WordPress buyer fields such as email, first name, last name, and display name; Payments-owned fields such as company name, customer address, separate billing details, customer type, and VAT/tax ID; the Groups-owned group/team name field when the checkout creates a group; and native gift checkout fields when gifting is enabled for the offer. Each instance uses an ordered field list where every row chooses a source and a concrete field. You can place the same element multiple times, for example one instance for contact fields and another for billing, tax, or gift fields. BricksMembers merges all instances into one checkout payload.

If the Member Profiles module is enabled, BRM Checkout Fields can also render supported custom profile fields that were explicitly marked as available in checkout under BricksMembers → Profile Fields. Add a profile-field row in the checkout field list, then select the exact custom profile field for that row. Supported checkout field types are text, textarea, email, URL, number, date, select, and checkbox. Image/upload fields stay post-purchase profile fields because provider handoffs need a small JSON-safe checkout payload.

If no eligible native provider is available for the chosen offer, BRM keeps the checkout wrapper visible but does not mount the payment UI. Visitors see a clear unavailable message instead of a broken form. For layout work, use the global Payments Checkout Preview Mode or the BRM Checkout Context Builder Provider Preview. Both can show provider choices before credentials or provider mappings are connected, but real checkout attempts remain blocked while preview mode is active. When you select an individual checkout child element in the Bricks builder, BRM also renders example checkout markup for that element so you can style it without needing the whole checkout context selected. Technical checkout errors are kept in server logs instead of being exposed to visitors.

Testing native provider webhooks: When you use native Payments with Stripe, PayPal, or Square, test with a real BRM checkout flow in the provider’s test or sandbox mode. Do not test native Payments by manually sending a generic provider event from the provider dashboard. BRM creates checkout sessions with offer, provider, consent, tax, and customer context; a synthetic checkout.session.completed event from Stripe or a similar manual event usually does not include that BRM checkout context, so it can appear in the events log without creating the expected payment, subscription, or access record.

Set Up Taxes and Invoices

Taxes and invoices are part of the Payments module, but they are not the same setup screen. Tax calculation lives in BricksMembers → Payments → Taxes. Invoice numbering, seller details, PDF templates, demo invoices, and issued invoice downloads live in BricksMembers → Payments → Invoices.

Taxes

Use Payments → Taxes when BRM should calculate tax before checkout or store tax evidence for invoices and reporting. The setup screen lets you acknowledge merchant responsibility, enable tax calculation, choose the tax engine, choose a fallback engine, set exclusive or inclusive pricing, choose a default product tax code from Stripe tax codes or BRM’s curated Stripe-compatible fallback list, decide whether billing address collection is automatic or always required, choose tax evidence retention in years, and enable VAT/GST ID collection. New installations default the product tax code to On-demand online courses – streamed audio/video because digital courses are a common BRM checkout product; change it per site or per offer when the sold product is different.

For Stripe checkouts, BRM still owns the native checkout step and the offer settings, but Stripe Tax runs inside Stripe Checkout. When tax is enabled for the offer and the tax engine is Stripe Tax, BRM sends Stripe Checkout the automatic tax, tax-ID collection, and billing-address collection settings. Stripe then calculates and displays the final tax in the Stripe Checkout step and returns the tax evidence through webhooks for BRM invoices and reporting.

Before relying on Stripe Tax in production, enable Stripe Tax in the Stripe Dashboard and add an active tax registration for every jurisdiction where the merchant is required to collect tax. If the checkout or Taxes screen says that no active Stripe Tax registration was found, BRM is connected to Stripe but Stripe Tax is not ready to calculate tax for that account yet. Add the registration in Stripe first, then refresh the BRM tax readiness status.

For embedded Stripe payment forms, register the checkout domain in Stripe under Payment method domains before going live. Card fields can render without that domain registration, but wallet and domain-bound payment methods such as Apple Pay, Google Pay, Link, Klarna, or PayPal can stay unavailable until Stripe has the domain on file.

For Stripe checkouts, BRM can show address and VAT fields on the checkout page so the order summary can preview tax before the customer continues. The default country field shows readable country names with the country code, for example “Germany (DE)”, and supported countries can expose a region/state dropdown when BRM has known subdivisions for that country. Existing Bricks-authored checkout pages that still use the older country text input are upgraded by the checkout runtime into the same country dropdown, so buyers do not need to type raw ISO codes such as “DE”. That preview is informational: BRM does not send a separate preflight tax payload into Stripe checkout creation, and Stripe still confirms the final tax amount in the secure Stripe Checkout step. One-time PayPal and Square flows use the same BRM-side fields as required pre-checkout tax input because those providers need BRM to calculate the tax before handoff.

For German or EU-style tax-inclusive digital membership pricing, start with the EU OSS (digital services) preset or configure the same essentials manually: acknowledge merchant responsibility, enable tax calculation, set Tax engine to Stripe Tax, set Tax behavior to Inclusive, choose the closest product tax code from the dropdown, enable VAT/GST ID collection when business buyers are allowed, and use Billing address collection: Always required when you need reliable tax location evidence. Auto is lower friction, but it leaves more of the collection decision to Stripe and can be less deterministic for VAT-heavy flows. The fallback engine only matters when BRM itself has to run a tax-engine calculation; using Stripe Tax as both primary and fallback is not a real fallback if Stripe Tax is not ready. If Stripe Tax is not ready, the Taxes screen and checkout preview explain the reason, such as a missing active Stripe Tax registration or missing Stripe secret key.

The tax engines shown in the current admin are Stripe Tax, Rates table, Avalara, and TaxJar. Manual rates use BRM tax classes and rate rows. You can apply a preset, add common jurisdiction rows, add or edit individual rates, import rate rows from CSV, and export tax reports from the same Taxes tab.

The Taxes tab also has a Review queue, Reports, and a provider-support table. That provider-support table matters for checkout: when tax is enabled, BRM can block recurring checkout for a provider if that provider cannot carry the tax data safely for the selected offer.

Use BRM Checkout Fields for tax and billing inputs. Add the company, address, customer type, and VAT/tax ID rows that your checkout needs. Country fields show readable names with ISO country-code values, and region fields can switch to country-specific dropdowns when BricksMembers has known subdivisions. Separate billing details can represent a different payer or invoice recipient; they are used for tax preview, invoices, and provider handoff without overwriting the buyer’s WordPress profile.

data-brm-checkout-summary-subtotal, data-brm-checkout-summary-tax, and data-brm-checkout-summary-total mark order-summary text targets. BRM updates subtotal and total immediately from the active checkout currency and updates tax after tax preview when BRM-side preview is used
Legacy data-brm-tax-* and data-brm-checkout-address-* attributes still work for older saved checkout pages, but they are no longer the normal setup path for new templates

Use checkout helper tags for labels and messages around your checkout layout: {brm_checkout:tax_label}, {brm_checkout:total_label}, {brm_checkout:tax_b2b_toggle_label}, {brm_checkout:tax_vat_id_label}, {brm_checkout:tax_vat_id_hint}, {brm_checkout:tax_vat_id_valid}, {brm_checkout:tax_vat_id_invalid}, {brm_checkout:tax_vat_id_unavailable}, {brm_checkout:tax_reverse_charge_notice}, {brm_checkout:tax_address_incomplete}, and {brm_checkout:tax_previewing}.

Invoices

Use Payments → Invoices for invoice settings and PDF output. The current screen lets you choose the active invoice template, set the invoice series, starting number, number format, fiscal-year start month, due days, money format, and whether demo invoices and tools are shown.

The same Invoices tab stores the seller and invoice text used by generated PDFs: seller name, country, tax ID, email, logo URL, seller address, reverse-charge text, invoice notes, and terms and conditions. Seller name and address can also inherit from the Email module business settings.

Invoice templates are hidden brm_invoice_template posts surfaced through the Invoices tab. Create one from the Classic or Modern starter, then edit it in the visual PDF designer. The issued invoices table on the same tab shows invoice number, customer, date, total, status, and a PDF download action.

For invoice PDFs, use the designer placeholders that match the legal output you need. The current placeholder catalog is fixed in code and includes seller, buyer, invoice, item, total, tax, payment, and footer fields:

Seller: {{seller_name}}, {{seller_address_line}}, {{seller_country}}, {{seller_tax_id}}, {{seller_email}}, {{seller_logo_url}}
Buyer: {{buyer_name}}, {{buyer_first_name}}, {{buyer_last_name}}, {{buyer_company_name}}, {{buyer_address_line}}, {{buyer_country}}, {{buyer_tax_id}}, {{buyer_tax_id_masked}}, {{buyer_email}}, {{buyer_type}}, {{group_name}}
Billing recipient: {{billing_name}}, {{billing_email}}, {{billing_company_name}}, {{billing_address_line}}, {{billing_country}}
Invoice: {{invoice_number}}, {{invoice_series}}, {{invoice_date}}, {{due_date}}, {{fiscal_year}}, {{invoice_status}}
Items and totals: {{line_items}}, {{currency}}, {{subtotal}}, {{tax_total}}, {{tax_total_label}}, {{total}}
Tax, payment, and footer: {{tax_breakdown}}, {{reverse_charge_text}}, {{paid_at}}, {{payment_method}}, {{merchant_notes}}, {{terms_and_conditions}}

For legal invoices, use {{buyer_tax_id}} when the full customer tax or VAT ID should appear on the PDF. Use {{buyer_tax_id_masked}} only when you intentionally want the masked version. The {{line_items}} table prints item, quantity, unit amount, tax rate, tax amount, and line amount. The {{tax_breakdown}} table groups tax lines by jurisdiction and tax type.

Billing email automations can use the same checkout customer details with email placeholders such as {{buyer_first_name}}, {{buyer_last_name}}, {{buyer_company_name}}, {{billing_name}}, {{billing_email}}, {{billing_company_name}}, {{buyer_tax_id}}, and {{group_name}}. Checkout-enabled custom profile fields are available by key with {{profile_field_FIELDKEY}}, for example {{profile_field_department}}.

Demo invoices are safe for template previews. They use demo rows and demo numbering, so they do not consume real invoice numbers.

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:payment_method}, {brm_billing:payment_method_brand}, {brm_billing:payment_method_last4}, and {brm_billing:payment_method_label} return stored payment-method display data for the resolved subscription when the provider supplies it
{brm_billing:invoice_url} returns the current user’s BRM invoice download links as HTML anchors in content text, or an empty string when the user is logged out or has no invoices. In single dynamic-tag fields it follows subscription resolution first, so for flexible invoice cards and invoice-only account pages, prefer a BRM User Invoices query loop with invoice item tags.
{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}, {brm_billing:item:features}, {brm_billing:item:features_text}, {brm_billing:item:content}, {brm_billing:item:image}, {brm_billing:item:image:url}, {brm_billing:item:image:id}, {brm_billing:item:image_url}, {brm_billing:item:image_id}, {brm_billing:item:has_trial}, {brm_billing:item:trial_days}, {brm_billing:item:trial_label}, 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 and payment-document fields like status, provider, period_start, period_end, amount, currency, paid_at, receipt_url, invoice_url, and status_badge are empty, and {brm_billing:item:cancel_at_period_end} returns 0.

Since 0.9.95, BRM Billing Offers loops also include an Offer Keys query control. Enter comma-separated offer keys when a template should render a curated set of offers, for example starter_monthly,pro_monthly,team_monthly,lifetime_all_access.

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}, {brm_billing:item:cancel_at_period_end}, {brm_billing:item:payment_method}, {brm_billing:item:payment_method_brand}, {brm_billing:item:payment_method_last4}, and {brm_billing:item:payment_method_label} 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 Checkout Context: checkout-aware tags come first. {brm_checkout:url_offer_key} returns the active URL-parameter offer key, and offer-style {brm_billing:item:*} tags resolve the active checkout offer before BRM falls back to a normal billing loop. That makes it easy to print the selected offer label, description, feature list, offer image, trial label, billing model, enabled providers, or default provider on one reusable checkout page.

Checkout tax helper tags are intentionally text-only. Use them when you build your own tax controls with normal Bricks text, form, and layout elements. For example, {brm_checkout:tax_b2b_toggle_label} can label a business-buyer toggle, {brm_checkout:tax_vat_id_label} and {brm_checkout:tax_vat_id_hint} can label the tax ID field, and {brm_checkout:tax_reverse_charge_notice} can appear in the tax summary.

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:receipt_url} returns the provider receipt URL when stored. {brm_billing:item:invoice_url} remains the provider-hosted invoice URL. For a BRM-generated invoice PDF tied to that payment, use {brm_billing:item:invoice_download_url} on the Invoice button. {brm_billing:item:transfer_url} returns the native access-transfer URL when that one-time payment is eligible for transfer. {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. The current runtime includes payments attached to subscriptions and standalone one-time payment rows for the current user.

Inside a BRM User Invoices loop: {brm_billing:item:id}, {brm_billing:item:status}, {brm_billing:item:amount}, {brm_billing:item:currency}, {brm_billing:item:paid_at}, {brm_billing:item:invoice_number}, {brm_billing:item:invoice_date}, {brm_billing:item:invoice_due_date}, {brm_billing:item:invoice_subtotal}, {brm_billing:item:invoice_tax}, {brm_billing:item:invoice_total}, {brm_billing:item:invoice_download_url}, and {brm_billing:item:status_badge} read from the current BRM invoice row. Use {brm_billing:item:invoice_download_url} on a normal Bricks button link. In this invoice loop, {brm_billing:item:invoice_url} resolves to the same BRM invoice download URL.

For downloadable invoice templates, use {{tax_total_label}} next to {{tax_total}}. In the current runtime that placeholder resolves to Tax.

Use {{buyer_tax_id}} for the customer’s tax or VAT ID on invoice PDFs. That placeholder prints the full tax ID from BricksMembers’ encrypted tax evidence. The masked placeholder is available for privacy-focused screens, but it is not the right choice for the legal invoice itself.

Invoice templates should also include the line_items table placeholder. That table prints what the invoice is for, including item, quantity, unit amount, tax rate, tax amount, and line amount. The Classic and Modern starters already include that middle invoice-items table.

In the WordPress admin, invoice work lives under BricksMembers → Payments → Invoices. That tab contains issued invoices, invoice PDF downloads, invoice settings, seller details, legal notes, terms, active-template selection, demo invoice creation, counter reset tools, and template creation from the Classic or Modern starter layout. Use Payments → Taxes for tax calculation, rates, classes, reporting, and tax review work.

That combination is what makes it possible to build account pages that show active subscriptions, recent payments, invoices, 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.

How Gift Memberships Fit Into Payments

The Payments module now also works with the dedicated Gifting feature. This matters most when you want a true gift checkout flow instead of a normal purchase that gets reassigned later.

When both Payments and Gifting are enabled, BRM can show native gift fields inside the checkout context. Add gift rows inside BRM Checkout Fields for the gift toggle, recipient email, recipient name fields, and optional message.

Enable Gifting in BricksMembers → Modules.
Open BricksMembers → Gifting and confirm Enable Subscription & History is on. Payments requires that shared gift-record mode.
Open BricksMembers → Payments and enable native gifting globally.
Open the relevant offer in Payments → Offers and allow gifting for that offer.

From there, BRM handles the rest of the gift flow: payment, stored gift record, claim email, and recipient claim. If you use WooCommerce, SureCart, or FluentCart instead of native checkout, the Gifting feature still helps, but the practical flow is usually a post-purchase transfer rather than a native Payments checkout gift.

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

If you want the deeper gift-checkout and claim flow, pair this guide with the dedicated gifting guide. Payments now handles native checkout gifting, while the Gifting module owns the broader transfer and history behavior around it.