Introducing Salable Only Subscriptions: Access Without Payment

You may want to handle invoicing for certain customers separately or not invoice them at all but still want to provide access to your SaaS app immediately. Your customer success team needs to use your product to do their jobs. Your integration partner needs access to build a connector. The prospect you're courting needs a trial environment that doesn't require them to hand over a credit card at the start of a sales conversation. The customer who experienced two hours of downtime last Tuesday deserves a period of complimentary access.

Until now, handling these cases in Salable meant working around your own billing system—provisioning access outside the platform you use for everything else, managing it separately, and hoping the two systems stayed in sync. Today that changes.

Salable Only Subscriptions let you create fully functional subscriptions directly from your dashboard without touching Stripe. No checkout flow, no payment. Just access, managed through the same entitlement system.

The Problem with Managing Access Outside Your Billing System

When your access control lives in your billing system, every exception creates a decision: do you route this person through checkout, or do you manage their access some other way?

Routing users through an unnecessary checkout process can create a bad user experience. You're forcing a partner developer through a payment form they should never see. You're asking your own support staff to hold a company card number. You're creating test subscriptions in your billing provider that inflate your customer counts and cloud your analytics.

Managing their access outside your billing system is worse. Now you have two sources of truth for who can use what. Your entitlement checks might look at billing for paying customers and a separate database flag for exceptions. Those systems drift apart. The support engineer who was provisioned access in the ad-hoc system still has it two years later after they've moved to a different role. The partner who stopped integrating with your platform is still active because nobody thought to revoke the manual flag.

The right answer is a single entitlement system that handles both cases—and that's exactly what Salable Only Subscriptions provide.

What They Are

A Salable Only Subscription is a subscription created directly in Salable that bypasses the Stripe payment process entirely. It behaves identically to a subscription created through checkout: it assigns entitlements, supports grantee groups, supports usage recording, respects tier tag constraints, and participates in all the same lifecycle management your paid subscriptions use.

The only difference is that no invoice is generated and no payment is collected in order to generate the subscription. From your application's perspective, when it calls the Salable API to check whether a user has access to a feature, the response is the same as users with standard subscriptions.

Who This Is For

There are several use cases for Salable Only Subscriptions including the following:

Your internal teams. Your engineers, product managers, designers, and support staff all need to use your product to understand it and improve it. Running them through checkout creates unnecessary friction and produces billing records that distort your customer metrics. A Salable Only Subscription gives them full access under your standard entitlement system, which also means their experience accurately reflects what customers see—important when they're investigating bugs or evaluating whether a new feature works as intended.

Technology partners and integration developers. When another company builds an integration on top of your platform, they need access to develop, test, and maintain it. The value exchange isn't monetary—it's the ecosystem growth and distribution they bring. A Salable Only Subscription formalises that access relationship without requiring a billing arrangement, and because it lives in your standard subscription system, it shows up in your records and can be revoked cleanly when the relationship ends.

Sales-led trials and demo environments. Not every customer journey starts with self-serve checkout. Enterprise prospects often need access provisioned before they've signed anything, and requiring them to enter payment details at the start of a sales engagement creates friction at exactly the wrong moment. A Salable Only Subscription with an expiry date matching your trial window gives the prospect proper access while keeping your pipeline in motion.

Goodwill and service recovery. When something goes wrong—extended downtime, a billing error, a feature that didn't work as advertised—granting a period of complimentary access is a meaningful gesture. A Salable Only Subscription lets you do this precisely, for the right plans and the right duration, documented in the same system where the rest of your customer relationships live.

Beta programs and early access. Beta testers are providing something valuable: real usage, real feedback, and the validation that your next feature actually works in the field. Paying them with a paywall doesn't make sense—but neither does provisioning their access with a database flag that you'll forget about in six months. A Salable Only Subscription with a defined expiry keeps your beta program clean and automatically revokes access when the window closes.

Manual invoicing. Some business relationships operate outside automated billing. Enterprise customers on purchase orders, customers in regions where card payments aren't practical, deals negotiated with custom payment terms—in all of these cases, payment happens outside Stripe but access still needs to be granted inside your application. A Salable Only Subscription lets you provision access immediately when payment is confirmed, without routing the customer through checkout. Your entitlement records stay accurate regardless of how the underlying payment was handled.

Lifecycle Options

Because Salable Only Subscriptions aren't tied to a Stripe billing cycle, you define the lifecycle directly when creating the subscription. Three models are available.

Interval-based works like a standard recurring subscription. You set an interval—day, week, month, or year—and an interval count, and the subscription renews accordingly. This is the right choice when access should continue indefinitely with explicit renewal, such as for a permanent internal team member or an ongoing partner relationship. For example, a monthly subscription uses an interval of "month" with a count of one; a quarterly subscription uses "month" with a count of three. You can also configure the subscription to not automatically renew when it expires, scheduling it to terminate cleanly at the close of the current period.

Expiry date terminates the subscription automatically on a date you choose. No renewal, no action required to end it. This is ideal for trials, beta programs, and goodwill periods where you know upfront exactly how long access should last. Set the date, create the subscription, and the entitlement system handles the rest.

Perpetual creates a subscription that never expires and never renews. It stays active indefinitely until you explicitly cancel it. Permanent partner access and internal tooling where there's no meaningful renewal cycle benefit from this model—you don't want the subscription to expire on its own, but you also don't want to think about renewal dates.

Creating Your First Salable Only Subscription

Creating a Salable Only Subscription takes about thirty seconds from the Subscriptions page in your dashboard. Click Create Subscription, select a product and one or more plans—plans must have at least one line item and one entitlement configured to be eligible—specify the owner receiving access, optionally specify a grantee or group, configure the lifecycle, and create.

The subscription is active immediately. The owner's entitlement checks will reflect the new access from your next API call.

What Stays the Same

Because Salable Only Subscriptions participate fully in the standard entitlement infrastructure, you benefit from everything that already works. Tier tag constraints prevent conflicting plans. Grantee Groups work exactly as they do for paid subscriptions. Plans with metered line items track usage correctly. Per-seat plans still support full seat provisioning and management, including group assignments and quantity adjustments. All webhook events with the exception of the receipt.created event fire for Salable Only Subscriptions, keeping your application in sync with lifecycle changes.

What you don't get is anything tied to payment: no invoices, no receipts, no Stripe involvement, no proration calculations, no dunning retries. If you later want to transition a user from complimentary access to a paid subscription, cancel the Salable Only Subscription and direct them through your standard checkout flow.

One System for All Access

Salable Only Subscriptions make decoupling payment and app access possible. Whether someone earned access by paying, by being on your internal team, by joining a beta program, or by receiving goodwill credit after a service interruption—your application sees a subscription with active entitlements. One system, one check, one source of truth.

Your paying customers' access is already managed through Salable. Now the rest of your access relationships can be too.