Polar: a billing platform for AI products, reviewed for adopters

What Polar solves, and who it is for

Polar describes itself as a billing platform, and the README positions it specifically for AI startups that need to charge for tokens, agents and compute without building billing infrastructure. That framing matters because the hard part of usage billing is not the checkout page. It is metering events accurately, mapping them to prices, and keeping the invoice correct when a customer retries a call or a job fails midway.

The README lists the pricing models the product supports: usage billing, subscriptions, seats, credits, trials and discounts, which can be composed. It also states that Polar acts as merchant of record, taking on receipts, customer accounts, dunning, sales tax and VAT. That combination is the actual pitch. A team that only needs a one-off payment link is not the target audience; a team that bills per API call or per GPU second is.

The repository topics confirm the same scope: digital-products, merchant-of-record, payments, subscriptions and usage-billing. The project is not a general accounting system and the README does not present it as one.

How the Polar repository is put together

The top-level layout is a monorepo. There is a server/ directory, a clients/ directory, an sdk/ directory, and separate infra/, terraform/ and lambda/ directories. The README credits a Python stack for the backend, naming FastAPI, Pydantic, SQLAlchemy, Dramatiq, Uvicorn and httpx-oauth, and a JavaScript stack for the front end, naming Next.js, TanStack Query, Tailwind CSS and axios. The repository topics list fastapi, nextjs and turborepo, and the root package.json declares pnpm as the package manager at version 10.28.1.

That split tells you where the work sits. The backend owns the billing logic and the API, the clients directory holds the Next.js application, and sdk/ holds the published SDK packages. The recent releases are tagged under sdk/, for example sdk/1.0.0-alpha.22, which is consistent with the SDK being versioned separately from the server.

The README points to two external SDK repositories, polarsource/polar-js for JavaScript and polarsource/polar-python for Python, rather than keeping them inside this repository. So an integrator has a choice: use the hosted API and one of those SDKs, or run the server from this repository. Those are different projects with different maintenance burdens, and the README does not treat them as equivalent.

Installing Polar and making a first API call

The README does not give install commands for the server. It says the DEVELOPMENT.md file contains what you need to configure a development environment, and it links to polar.sh/docs for product documentation and polar.sh/docs/api-reference for the API reference. Because the README gives no package name, no port and no environment variables for a local install, there is nothing to reproduce here without inventing it.

What the README does document is the integration path for an application: the public API and the webhook API. The two maintained SDKs are published separately, and the Python one is the natural fit for a Python service. The README gives no code sample for either SDK, so the example below is deliberately limited to what the README states about where to find the API reference and the SDK repositories.

# The README points to these locations rather than giving install commands:
#   https://polar.sh/docs
#   https://polar.sh/docs/api-reference
#   https://github.com/polarsource/polar-python
#   https://github.com/polarsource/polar-js

For a first real use, the README's own description of the webhook API is the place to start, because usage billing depends on events reaching Polar. The README links to polar.sh/docs/integrate/webhooks/endpoints for that. A reader should expect to configure an endpoint in the Polar dashboard, then send metered events from their application. The README does not state the event schema, the retry policy or the signature verification method, so those have to come from the API reference.

If you want to run the platform itself, start with DEVELOPMENT.md and the flake.nix file at the repository root, which suggests a Nix-based setup is supported. The README does not describe that path, so treat DEVELOPMENT.md as the authority.

Where Polar's model creates friction

The merchant-of-record arrangement is the largest structural decision here. Polar takes on sales tax and VAT, receipts and dunning, and in exchange it sits between you and your customer for the transaction. The README states this plainly. What it does not state is how disputes, refunds or payout timing work, and none of that is in the README, so anyone whose finance process depends on those details needs to read the fees documentation linked from the README before assuming anything.

The SDK versioning is the second friction point. The most recent release listed is sdk/1.0.0-alpha.22, published on 2026-09-15, preceded by alpha.21 and alpha.20 in the same month. An alpha version number is a signal about API stability, and the README does not claim otherwise. Teams that pin dependencies and avoid pre-release versions will find that constraint awkward.

Third, the README is a product page, not an operator's manual. It does not document rollback, migration between pricing plans, or what happens to in-flight usage events during a deploy. Those gaps are real for anyone running the server themselves rather than using the hosted service, and the repository's own DEVELOPMENT.md is the only in-repo pointer the README offers.

Finally, the repository is a monorepo that includes terraform/ and infra/ directories. Running it yourself means owning that surface. For a small team, that is likely more than they want.

Polar compared with assembling billing from a payment processor

The obvious alternative is to take a payments processor directly and build the billing layer on top. With a raw processor you own the customer record, the subscription state, the usage aggregation, the invoice generation and the tax question. That is more code, but it also means no intermediary holds the merchant relationship and no third party decides how metering events are represented.

Polar's difference is that it bundles those pieces and takes the tax position. The README frames this as removing boilerplate and headaches, and for a team whose product is metered AI usage, the aggregation logic is the part most likely to be wrong on the first attempt. Offloading it is a genuine trade, not a marketing claim.

The cost is the layer itself. With a bare processor, a pricing change is a code change in your own system. With Polar, pricing models are configured in the platform, and the README lists the supported shapes: usage, subscriptions, seats, credits, trials, discounts. If your pricing does not fit one of those shapes, the platform's model becomes the constraint rather than the payment processor's API.

There is also a self-hosting middle path, since the repository is Apache-2.0 licensed and includes a server. Running it yourself keeps the merchant relationship in your hands, but you inherit the FastAPI, SQLAlchemy and Dramatiq stack and the infrastructure directories that come with it.

Licence and the cost of keeping Polar current

Polar is licensed under Apache License 2.0, and the LICENSE file sits at the repository root. For most adopters that is a permissive licence, but Apache-2.0 carries obligations around notices and modified files, and it includes a patent grant. Whether those obligations apply to your distribution depends on whether you ship the software or only call a hosted API. That is a question for your own counsel, not something the README answers.

The more practical cost is upgrade cadence. The SDK releases listed are dated 2026-09-04, 2026-09-11 and 2026-09-15, three alpha releases in under two weeks. That pace suggests the SDK surface is still moving, and a team that adopts it should expect to track releases rather than pin once. The last push to the repository was on 2026-09-21, which is the same day as the most recent activity recorded here.

The README's contribution section points to DEVELOPMENT.md for environment setup and to a Feedback button in the Polar dashboard for feature requests and bugs. There is no issue tracker workflow described in the README, which is worth knowing before you plan to file a bug report through GitHub. Security disclosures go through SECURITY.md instead.

Editorial conclusion

Adopt Polar if you sell usage-based or subscription products and want metering, checkout and tax handled together rather than assembled from parts. Do not adopt it if you need a stable SDK surface today, since the published SDK releases are still 1.0.0 alpha builds, or if you cannot accept merchant-of-record terms. Before committing, read the fees page linked from the README, confirm the licence obligations of Apache-2.0 for your distribution model, and check the DEVELOPMENT.md setup against your own infrastructure.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. polarsource/polar on GitHub
3. Project website
4. README
5. Releases