Native subscriptions and trials, a redesigned payments hub, smarter site content, and better client logos
Sell subscriptions and run no-card trials natively in Hub, navigate your finances from one redesigned payments hub, hide empty site sections automatically, and show client logos in the right style for every theme.
What's new in Hub
Today's update is a wide-ranging one — covering native subscription commerce, a completely reworked customer payments experience, smarter site content controls, and a set of improvements to how client logos look across light and dark themes.
Sell subscriptions and run free trials, natively in Hub
Hub now has a built-in subscription commerce system connected directly to your customer Accounts. You can create Free, One-off, and Recurring offers, set quarterly or annual pricing, and publish them to your site — all without building a separate integration.
Free trials with clear rules. You can configure no-card trials that end at a fixed deadline, or card-required trials that convert to a paid subscription when the customer confirms. Customers know exactly what they've agreed to: the trial terms are frozen at the point of sign-up and can't be changed mid-trial.
Benefits tied to products. Products can grant free access, fixed-duration one-off benefits, or recurring entitlements. If a customer holds multiple products, they automatically receive the highest-allowance version of each benefit. Organisation seat limits count active members and pending invitations together, with a transactional reservation guard so the limit is never exceeded.
Protected no-card trials. No-card Hub trials are now protected from inheriting metered AI overages or outstanding charges. The trial restriction is clearly explained in the customer interface, and the overage toggle is disabled for the duration.
Note: The full end-to-end purchase, renewal, and trial flow is live in the platform. Isolated Stripe and Firebase lifecycle acceptance (settlement, refunds, concurrency) is outstanding and will be confirmed separately before customer-facing promotion begins.
A redesigned customer payments and invoices hub
The customer Payments page has been completely reworked. Instead of a single stacked list of payment events, invoice cards, and a second search bar, customers now see a focused financial workspace with three clear areas:
- Invoices — with search, status, and date filters, download actions, and detail views
- Payment activity — a clean activity feed with its own status column and filter controls
- Shared invoices — for invoices shared across connected accounts
Visited-tab filters are remembered, cursor pagination keeps large histories manageable, and the invoice download and detail actions all continue to work through the existing route. The legacy invoice URL also resolves to the same list.
A visual polish pass followed immediately after: duplicate headings and a crowded payment-method button have been cleaned up, and the activity status column is now correctly labelled.
Account navigation is cleaner and more logical
The Overview page now reliably appears first in account navigation, regardless of how many starter pages share a navigation position. When the new combined Payments & Invoices page is enabled, the redundant legacy Invoices link is automatically hidden — so customers only ever see one route to their financial history.
Save email templates from the Hub editor
Saving an email template previously relied on a browser-native prompt that doesn't work inside Hub's embedded browser — so the action silently did nothing for many users. The Save as template and Turn into automation actions now use Hub's own dialog, which works everywhere, shows errors inline, and prevents accidental double-saves while a save is in progress.
Site service actions now save correctly
Service actions — the per-record overrides that control which booking, checkout, or request flow a site card or detail header uses — were being silently discarded when saved. They now persist correctly, survive publication, and apply as expected to both collection defaults and individual record overrides.
Choose how customers reach your services: forms, bookings, or checkout
Services on your site can now each have their own journey. You can choose between:
- An existing sign-up or external link
- A request form (including Hub's built-in forms)
- A native booking form
- A Stripe checkout
Cards and detail headers share the same resolver and editor, with collection-level defaults you can override per record. Existing destinations carry over automatically for services where no action is configured.
Automatic replies and follow-up settings for forms
Form builders now have a unified After submission section that groups thank-you content, destination redirects, file delivery, and immediate email replies in one place. A saved template creates or updates a form-specific workflow using the form_submitted or meeting_booked trigger — so the right follow-up runs automatically without any extra configuration.
Recipient replies resolve from the submitted contact email, independently of any portal sharing. Stable workflow idempotency prevents duplicate replies from being sent if a trigger fires more than once.
Manage form submissions and bookings alongside service orders
Sites now bring Orders, Submissions, and Bookings together in one place. Each accepted attributed response enters a private index; selected forms can create service orders automatically, while other submissions offer a one-click manual conversion. Service progress stays independent of payment and record status, so the operational picture is always accurate.
Authenticated APIs expose safe detail projections, original submitted answers, linked records, and completion-specific follow-up activity. Conversion and progress writes are audited on the linked record.
Related-content sections hide automatically when they're empty
Related-content sections can now hide themselves when their published results are empty — removing the background, inset, and surrounding space so your page doesn't show an awkward blank area. Showing a configurable empty message remains available as an alternative if you prefer.
Hiding is the default for both existing and new sections. The builder shows clearly whether a section will be visible or hidden on the published page.
Client logos display cleanly, without cropping or overlays
Testimonials and record pages that use a company logo were previously displayed as a cover banner — enlarging the logo behind the title and applying a dark overlay, which distorted most logos. A new Client logo header layout displays the full image on a small, contained surface above the title, preserving its proportions and keeping text separate.
The layout selector offers five choices and fits comfortably in narrow editor panels.
Client logos automatically switch for light and dark themes
If a record has both a standard and a dark-mode logo variant, Hub now selects the right one automatically based on the visitor's active theme — displayed on a transparent surface so it blends naturally with any page background. Records with only one logo continue to use their existing white frame.
This works for SVG logos as well as raster images, and was verified live at narrow viewport widths in both themes.
Automatic footer links can now be filtered and targeted
Automatic footer columns — the kind that pull in published records like Products or Articles — can now be filtered and directed to the correct detail page. For example, a Labs footer column can show only Products where Brand = Labs, linking through the Labs Sales product page, rather than mixing in Hub modules or sending visitors to the wrong site.
Automatic source controls also now use the same compact, consistent field inputs as the rest of the editor: 32 px high with 13 px text, with labelled rule status and aligned field bottoms.
Reliable header and footer references after slug changes
Saved headers and footers could retain an outdated internal ID after a slug change, causing a site to silently fall back to an older design instead of the updated one. Hub now reads designs using the current document ID, so the design you saved is always the design that appears. Trailing hyphens are also trimmed from newly generated slugs, so long workspace names don't immediately prompt a renaming step.
Agent email drafts can no longer be sent twice
A race condition could cause an agent's reviewed email reply to be delivered more than once — for example if a provider call succeeded but the result wasn't persisted before a retry ran. A transactional claim now locks the recipient, channel, and reviewed reply before the provider call, and finalises the draft and its Activity event together. Retries finish a saved result without sending again.
Unconfirmed outcomes remain locked and visible. Operators can record confirmed delivery or close the attempt — neither path unlocks the draft for a fresh send.
More improvements are in progress. We'll keep you updated as they roll out.