Arborist’s Direct Sales Stack: Sell a Mac App Without Becoming the Merchant of Record

A license to bill: Arborist’s direct-sales system for macOS

The part of Arborist’s setup that caught our attention is not the checkout page. Plenty of software businesses can put a payment form on the web. The difficult part is building a reliable bridge between a direct payment and a native Mac app that needs to know, immediately and accurately, whether someone has access. Arborist is a native macOS command center for git repositories and worktrees, and its core job requires running user-entered commands at arbitrary filesystem locations. Apple’s App Store sandbox was never a workable home for that product. That turns distribution into an operating decision rather than a marketing preference: if the product cannot fit the store’s rules, the company needs another way to acquire customers, collect payment, manage licensing, and grant access without assembling an unnecessary pile of billing infrastructure.

This is the useful lesson in Arborist’s approach. Direct distribution is not simply “put the download on a website.” A Mac developer selling outside the App Store inherits a set of connected jobs: establish an identity for the buyer, present a checkout experience people recognise, determine which product rights they purchased, communicate those rights to the application, and deal with the commercial obligations that come with taking payment. Arborist pairs RevenueCat’s web billing and entitlements with Stripe Managed Payments to turn those pieces into a system. The result is not a shortcut around the hard work of running a software business. It is a cleaner division of labour between the application, the billing layer, and the merchant-of-record layer.

[INFO_TABLE]
Product/Service: Arborist direct-sales billing system
App category: Native macOS command center for git repositories and worktrees
Distribution model: Direct web checkout outside the Mac App Store
Billing stack: RevenueCat Web Purchase Links + Stripe Managed Payments
Access control: RevenueCat entitlements linked to an iCloud-based user identifier
Checkout experience: Browser-based checkout with Apple Pay support
Price: Not specified
[/INFO_TABLE]

The real constraint is the sandbox, not the payment button

Arborist is a good example because the distribution decision is anchored in product reality. A tool that runs commands supplied by its user, in locations chosen by that user, does not have much room to compromise around a restrictive sandbox. Trying to force that workflow into a channel built around different technical assumptions would mean reshaping the product around the store rather than serving the customer’s actual work. That is backwards. The application should define the distribution architecture, especially for software used by technical teams whose workflows depend on local files, repositories, worktrees, terminals, and commands that do not fit neatly inside a tightly controlled container.

For an operator, this matters because single-channel growth is fragile even before policy becomes a problem. The Mac App Store can be a useful channel for products that fit its model, but it cannot be the entire distribution plan for software whose functionality sits outside that model. Arborist’s system creates a direct route from discovery to purchase to product access. That route is owned by the business rather than being dependent on a storefront’s sandbox rules. More importantly, it makes direct distribution operationally credible. A company can only treat a channel as strategic if payment, access, supportable account identity, and commercial administration work together after the customer clicks “buy.”

The entitlement is the product boundary

It took us a while to understand why entitlement design is the centre of this workflow rather than a technical footnote. In a direct-sales Mac app, the entitlement is the contract between the payment system and the application. It answers the practical question that matters after checkout: what can this customer use? Arborist begins by configuring entitlements in RevenueCat. That gives the business a defined access state that the app can read, instead of asking the application to interpret payment records, invoices, or a hand-built licensing database on its own.

That separation is important. The checkout layer has one job: complete a purchase. The app has another: provide or restrict access based on an entitlement. When those two concerns are fused into custom licensing logic, every product change creates more moving parts. A developer ends up managing payment events, licence issuance, access restoration, customer identity, and application state in one homemade system. Arborist’s structure keeps the app focused on entitlement status. RevenueCat becomes the layer that communicates the customer’s purchased access back to the application, while Stripe Managed Payments handles the payment and merchant-of-record side of the transaction.

This is the moment the architecture clicks: the licence is not merely a code emailed after purchase. It is a live access state tied to a recognised customer identity. That matters for a native app because the purchase happens in a browser while the value is delivered inside macOS. The system needs a dependable handoff between those environments. An entitlement gives the business a common language for that handoff. The browser says the transaction is complete; the billing layer records the right; the app refreshes its customer information; the entitlement becomes available; and the product unlocks the relevant access.

Identity comes before checkout

The weakest version of direct app billing treats identity as an afterthought. That is where licensing systems become confusing for customers and expensive for the company: someone pays on the web, opens the app, and the two environments cannot agree that they are the same person. Arborist avoids that disconnect by using an iCloud-based user identifier. The user is identified before being sent to checkout, so the eventual web purchase is attached to the same customer identity the Mac application uses to request entitlement information.

This is not flashy product work, but it is exactly the kind of plumbing that determines whether a direct-sales channel feels trustworthy. The operator does not want a support process built around manually reconciling payments with app access. The customer does not want to wonder why a completed payment has not unlocked the software. By passing an identified customer into the web purchase flow, Arborist gives the billing system an address for the access right. Once checkout is complete, the app can refresh the RevenueCat SDK and read the changed entitlement state through its normal customer-information flow.

The practical insight is that a browser checkout does not need to become a detached ecommerce island. In this model, it is simply one stage in a connected product system. The app knows who the customer is. The purchase link is associated with that identity. The payment creates access. The SDK refresh pulls that access back into the app. For developers who would otherwise build a separate licensing server just to keep web payments and native access in sync, that is the piece worth studying. Systems outperform manual effort when the handoffs are designed before customers arrive.

Why the browser checkout is a feature, not a compromise

Sending a Mac customer to a browser can initially feel like a compromise compared with an all-in-one App Store transaction. In Arborist’s case, it is the correct trade. The product already needs to live outside the store, and the browser provides a familiar place to complete a direct purchase. RevenueCat’s Web Purchase Links connect the offering to that checkout flow, while Stripe Managed Payments supports a payment experience that includes Apple Pay. The customer gets a payment method that feels native to the Apple ecosystem even though the sale itself is not routed through the Mac App Store.

That matters because direct distribution should not force the customer through a visibly improvised buying experience. A standalone app can be technically sophisticated and still lose trust if its checkout feels disconnected from the product. Apple Pay helps keep the payment moment recognisable; the identified purchase flow keeps it connected to access; and the entitlement refresh makes the return to the app functional rather than ceremonial. No part of that creates demand by itself. Discovery remains a business function, and a purchase link is not a growth strategy. But it gives a company a conversion destination it can confidently use across its own website, product-led onboarding, partnerships, content, and other distribution efforts.

The merchant-of-record problem is where direct sales become serious

The payment form is the visible part of selling software. Merchant-of-record responsibility is the part that makes many direct-sales plans more complicated than they first appear. When a developer sells software directly, questions around tax handling and refunds do not disappear simply because the product is downloaded from the developer’s site. They become part of the commercial system. That is why “just use Stripe” can be incomplete advice for a developer who wants to sell a Mac app without becoming a payments operations company along the way.

Stripe Managed Payments changes the structure of that problem by taking on the merchant-of-record role in this setup. That simplifies tax handling and refund administration for the direct seller. The distinction matters. Arborist is not trying to avoid the realities of selling software; it is choosing a provider model that absorbs a meaningful set of merchant-of-record duties. For a small software business, this can be the difference between having a direct channel that is genuinely manageable and having one that demands a growing collection of internal processes before it is ready to scale.

We would separate this clearly from the broader promise often attached to direct-to-consumer payments. Direct sales can create more control over the customer journey, but control is not the same as doing every operational task internally. The smart system keeps ownership of the distribution path and the product relationship while using specialised infrastructure for work that should not become the company’s differentiator. Arborist’s stack does that neatly: the app retains its native workflow, RevenueCat manages the access logic between web and app, and Stripe Managed Payments covers the merchant-of-record layer attached to the sale.

What the implementation flow actually looks like

The workflow is refreshingly direct. First, define the entitlement in RevenueCat: this is the access state the application will recognise after a successful purchase. Next, connect Stripe as the web provider and attach the relevant offering to a Web Purchase Link. The Mac app identifies the customer through its iCloud-based identifier, then opens the browser checkout for that identified customer. The buyer completes payment using the available browser checkout methods, including Apple Pay. After the purchase, the application refreshes the RevenueCat SDK. The SDK’s customer information and entitlement state now give the app the signal it needs to recognise the paid access.

That sequence may look straightforward on paper, but its order is doing important work. The entitlement is defined before the offering is sold. The offering is attached before the checkout is opened. The customer is identified before payment. The app refreshes access after checkout rather than assuming that a browser confirmation page is enough. Each stage has a single purpose, and together they prevent the common direct-sales failure where a payment succeeds but the product has no clear way to honour it. This is why billing integrations should be treated as growth infrastructure, not as an isolated finance project. Revenue depends on the connection between acquisition, payment, and delivered value holding together under normal customer behaviour.

• Define access: Create the entitlement that represents the paid product right.
• Connect billing: Use Stripe as the web provider and associate the offering with a Web Purchase Link.
• Identify the customer: Send the iCloud-identified customer into the browser checkout.
• Complete payment: Let the buyer use the web checkout, including Apple Pay where available.
• Refresh access in-app: Refresh the RevenueCat SDK so the purchased entitlement is available to the Mac application.

What this system unlocks-and what it does not

Arborist’s model unlocks a credible direct route for a Mac application that cannot be distributed through the App Store because of its underlying functionality. It provides a path from a company’s own distribution efforts to a browser purchase and back into native-app access. It also avoids making the developer construct a separate licensing system and take on the merchant-of-record role simply to sell software outside Apple’s store. That is meaningful leverage. The business can invest more of its effort in product quality, discoverability, and repeatable distribution rather than rebuilding commodity billing operations.

It does not turn every macOS application into the same kind of direct-sales business, and it does not remove the need for a deliberate product and distribution strategy. Arborist is a specific response to a specific product reality: an app whose command-running, filesystem-level workflow cannot fit the App Store sandbox. The useful takeaway is not that every developer should copy its exact identity structure or entitlement setup. The takeaway is that companies should design payments and access around the real shape of their product, then choose infrastructure that keeps the system coherent from customer discovery through to the moment the app unlocks.

The operator verdict

The most valuable thing about Arborist’s billing stack is its restraint. It does not pretend that direct sales are effortless, and it does not confuse a payment processor with an entire licensing strategy. Instead, it turns a difficult set of requirements into a clear system: identify the customer, sell through a web checkout, record the right as an entitlement, refresh that right inside the app, and let a merchant-of-record service take on the commercial responsibilities that should not become the developer’s full-time concern.

For an operator building a native Mac product outside the App Store, that is the decision framework worth carrying forward. Build on direct sales when the product requires it or when channel independence is strategically valuable-but build it as a complete access system, not as a checkout button attached to a download page. Visibility compounds only when the business has somewhere reliable to send the attention it earns. Arborist’s setup gives direct distribution that reliability: a path that can move a prospect from discovery to payment to working software without making the company become its own merchant of record or licence-server operator.