Polar vs Stripe in 2026: A Side-by-Side from the Team Shipping Both

Stripe gives you primitives. Polar pushes everything through the portal. And in 2026 there's now a third option, Stripe Managed Payments, that blurs the line. Those three approaches cover almost every billing decision you'll make for a Next.js SaaS today.

We ship production adapters for both Stripe and Polar inside the MakerKit Drizzle kit and the MakerKit Prisma kit. Both sit behind the same BillingProvider interface in our codebase. After running both in customer projects for a year, this post is the comparison we wish existed when we started building those adapters. We've updated it for Stripe's own merchant-of-record offering, which changes the math.

Quick answer: Pick Stripe direct for B2B, per-seat billing, feature entitlements, or any product where you want full control over checkout, dunning, and trials. Pick Polar for indie projects, OSS monetization, single-product subscriptions, or any product where you sell internationally and would rather not own EU VAT compliance. Consider Stripe Managed Payments if you're already deeply on Stripe, want MoR-style tax/fraud handoff, and accept that it's currently the most expensive MoR on the market (and still in limited rollout).

Tested with Stripe API 2026-04, Polar API v1, Better Auth 1.6, Next.js 16.x, as of May 2026. Stripe Managed Payments coverage based on Stripe's published docs and the 2024 Lemon Squeezy acquisition.

Polar vs Stripe (and Stripe Managed Payments) at a Glance

Quick Decision Matrix

The honest answer for most B2B SaaS: start with Stripe Direct. The honest answer for most indie or OSS projects in 2026: start with Polar. Stripe Managed Payments is the right answer for a narrow case — teams already heavily integrated with Stripe who would rather pay a premium than rebuild on a different MoR. The rest of this post explains why.

What Is Stripe

Stripe is a direct payment processor. You collect the money, Stripe moves it, and you own everything that happens around the transaction: tax registration, sales-tax filing, dunning, chargebacks, refund flow, fraud disputes. Stripe gives you primitives (subscriptions, invoices, customers, entitlements, billing meters) and expects you to compose them.

This is the model the rest of the SaaS industry has built on for the last decade. The upside is total control over how billing works. The downside is that you own every tax filing, chargeback, and refund yourself.

What Is Polar

Polar is a Merchant of Record (MoR). When a customer buys your product, Polar is the legal seller. Polar charges the card, collects EU VAT, files the tax returns, handles disputes, and pays you out net of fees. Your product code never sees a "calculate sales tax" code path because there isn't one to write.

Polar's surface is narrower than Stripe's by design. There's no API for canceling a subscription, no API for restoring one, no API for switching plans. Everything that touches the subscription lifecycle goes through Polar's hosted customer portal. That's the model, not a workaround.

What Is Stripe Managed Payments

Stripe Managed Payments is Stripe's own merchant-of-record offering, born out of the 2024 Lemon Squeezy acquisition. With Managed Payments enabled, Stripe becomes the legal seller of record for your transactions, handles sales tax / VAT / GST compliance in 80+ countries, and manages chargebacks, fraud, and disputes. You still talk to the same Stripe APIs you already know.

The trade-off is cost. Managed Payments charges a 3.5% Managed Payments fee on top of standard Stripe processing fees, which brings the effective rate to roughly 6.4% + $0.30 per domestic transaction. On international cards with currency conversion, the all-in cost frequently exceeds 8% or even 10%. As of May 2026, it's the most expensive merchant of record on the market.

A few important practical constraints:

• It's currently in private beta with limited country rollout (roughly 35 supported business countries, mostly North America, Western Europe, and select APAC markets)
• Does not currently support merchants in South Korea, China, India, Turkey, or Brazil
• Only available via Stripe Checkout, not for fully custom Stripe Elements integrations
• Stripe itself notes it "is not a good fit for those that rely on sophisticated subscription, metered, or hybrid billing structures"

If your billing logic is "monthly subscription, one product, hosted checkout," Managed Payments is a one-flag upgrade from your existing Stripe integration. If your billing is "base + per-seat + metered API calls with usage tiers," Managed Payments is the wrong product and Stripe will tell you so.

The Real Fork: Direct Processor vs Merchant of Record

This decision matters more than any feature checklist. It changes what code you write, what compliance you own, and what your fees look like. In 2026 the fork is three-way, not two-way:

For a US-only B2B SaaS billing $50/mo subscriptions, Stripe Direct costs less and the compliance burden is manageable. For a global indie product selling $9 lifetime licenses to a thousand customers in 40 countries, Polar's bundled VAT handling is worth significantly more than the 1.1% fee delta over Stripe Direct. Stripe Managed Payments wins in a narrow middle: teams already deeply integrated with Stripe Billing who want to hand off tax/fraud/compliance without re-platforming, and who have the margin to absorb the premium.

The rest of this post walks through how the Stripe Direct vs Polar fork shows up in code, with Stripe Managed Payments notes inline where relevant. Most of the Stripe-side mechanics described below also apply to Managed Payments, since it sits on top of standard Stripe APIs.

The Unified Interface

Both providers in MakerKit implement the same BillingProvider interface. Here's the relevant slice:

// packages/billing/core/src/types/provider.ts
export interface BillingProvider {
  readonly name: string;
  readonly capabilities: ProviderCapabilities;
  checkout(params: CheckoutParams): Promise<CheckoutResult>;
  portal(params?: PortalParams): Promise<PortalResult>;
  listSubscriptions(params: ListSubscriptionsParams): Promise<PaginatedSubscriptions>;
  cancelSubscription(params: CancelSubscriptionParams): Promise<{ success: boolean }>;
  restoreSubscription?(params: RestoreSubscriptionParams): Promise<void>;
  updateSubscription?(params: UpdateSubscriptionParams): Promise<UpdateSubscriptionResult>;
  updateSubscriptionQuantity?(params: UpdateSubscriptionQuantityParams): Promise<UpdateSubscriptionResult>;
  listEntitlements?(customerId: string): Promise<Entitlement[]>;
  hasEntitlement?(customerId: string, lookupKey: string): Promise<boolean>;
  getMeterUsage?(params: GetMeterUsageParams): Promise<MeterUsageSummary[]>;
  recordMeterEvent?(params: RecordMeterEventParams): Promise<void>;
}

Look at the optional methods (?) versus the required ones. That distinction is the whole comparison. Both providers can do checkout, portal, and list subscriptions. Polar opts out of programmatic cancel/restore by throwing at runtime, opts out of entitlements entirely, and supports usage meters with an important caveat we'll get to.

Provider Capabilities (Declared, Not Inferred)

Each provider declares what it supports so the UI and server actions can adapt. From the kit:

// packages/billing/stripe/src/stripe-provider.ts
get capabilities() {
  return {
    name: 'stripe',
    supportsRestore: true,
    supportsCancel: true,
    supportsPlanSwitch: true,
    supportsPortal: true,
    supportsOrganizations: true,
    supportsEntitlements: true,
    supportsUsageMeters: true,
    supportsSubscriptionUpdates: true,
    // ...
  };
}

// packages/billing/polar/src/polar-provider.ts
get capabilities() {
  return {
    name: 'polar',
    supportsRestore: false,
    supportsCancel: false,
    supportsPlanSwitch: false,
    supportsPortal: true,
    supportsOrganizations: true,
    supportsEntitlements: false,
    supportsUsageMeters: true,    // all-time only
    supportsSubscriptionUpdates: true,
    // ...
  };
}

When the UI renders a billing page, it reads capabilities and hides buttons accordingly. Polar customers don't see a "Cancel Subscription" button; they see a "Manage Billing" button that opens Polar's portal. It's how Polar wants you to build it.

Cancel and Restore: Programmatic vs Portal

If you call cancelSubscription on the Polar adapter, this is what runs:

// packages/billing/polar/src/polar-provider.ts
cancelSubscription(_params: CancelSubscriptionParams): never {
  throw new Error(
    'Cancel not supported via Polar provider. Use portal for subscription management.'
  );
}

The same is true for restoreSubscription. Polar's design assumption is that subscription lifecycle changes happen in the customer's view, not in your application code. If you've built a "cancel anytime, one click" flow with Stripe, you can't port it to Polar without redirecting users out to Polar's portal.

For consumer SaaS, frictionless in-app cancellation matters for retention. Indie products where cancellation is rare can usually live with the portal redirect.

Webhook Hook Surface

The events each provider sends tell you what each one thinks you own. Here's the directory listing from our kit:

The asymmetry is the story. Stripe gives you three trial-lifecycle events because Stripe assumes YOU own dunning. You wire up on-trial-ending to send the "your trial ends in 3 days" email. You wire up on-payment-failed to start your retry sequence. You own the messaging, the timing, the retention logic.

Polar gives you zero trial events because Polar's MoR model owns dunning. When a trial ends or a payment fails, Polar's system handles the customer notification and retry. You get a single on-customer-state-changed event when the resulting state stabilizes (active, past_due, canceled). You get less control over the messaging, but also less to build and maintain.

Pick the one that matches what you want to be responsible for.

Checkout: Plans vs Products

Stripe checkout in the kit:

// packages/billing/stripe/src/stripe-provider.ts
async checkout(params: CheckoutParams) {
  const planMeta = this.getPlanMetadata(params.planId);
  const result = await this.auth.api.upgradeSubscription({
    headers: await headers(),
    body: {
      plan: planMeta.name,
      referenceId: params.referenceId,
      subscriptionId: params.subscriptionId,
      seats: params.seats,          // native seat support
      customerType: params.customerType,
      metadata: params.metadata,
      successUrl: params.successUrl,
      cancelUrl: params.cancelUrl,
      disableRedirect: true,
    },
  });
  return { url: result.url || '' };
}

Plans are first-class. You pass a plan name and a seat count, Stripe figures out the rest. If your plan has multiple line items (base + per-seat + metered usage), Stripe assembles a single subscription out of them.

Polar checkout looks similar from a distance but has a hard constraint:

// packages/billing/polar/src/polar-provider.ts
private getPolarProductsForCheckout(planName: string): string[] {
  const plan = this.findPlanByName(planName);
  const productIds = plan.lineItems
    ?.filter((item) => Boolean(item.productId))
    .map((item) => item.productId as string);
  if (productIds && productIds.length > 1) {
    throw new Error(
      `Plan ${planName} has multiple Polar products. ` +
      'Polar only supports a single product/price per subscription. ' +
      'Combine meters in Polar and configure one productId or planId.'
    );
  }
  // ...
}

One subscription, one product. If your pricing model is "base $20/mo + $5/mo per seat + $0.01 per API call," Stripe handles that as one subscription with three line items. Polar requires you to model it as a single product with bundled metering, or as separate purchases. That's a meaningful architectural constraint, and one that comes up the moment your pricing gets the slightest bit complex.

The Polar Authorization Gotcha

This one is genuinely undocumented elsewhere and cost us time when we built the adapter.

Polar's Better Auth plugin does not enforce reference-based authorization on billing operations out of the box. If your routing isn't airtight, a logged-in user could trigger checkout for any organization ID they can guess. We had to add an explicit authorization layer:

// packages/billing/polar/src/polar-provider.ts
private async checkAuthorization(referenceId: string, permission: string) {
  if (!this.authorizeReference) {
    throw new Error(
      'Authorization callback not configured for Polar provider. ' +
      'Configure authorizeReference to enforce billing permissions.'
    );
  }
  const authorized = await this.authorizeReference({ referenceId, permission });
  if (!authorized) {
    throw new Error(
      `Unauthorized: insufficient permissions for billing ${permission} operation`
    );
  }
}
async checkout(params: CheckoutParams) {
  await this.checkAuthorization(params.referenceId, 'create');
  // ...
}
async listSubscriptions(params: ListSubscriptionsParams) {
  await this.checkAuthorization(referenceId, 'read');
  // ...
}
async portal(params?: PortalParams) {
  await this.checkAuthorization(params.referenceId, 'update');
  // ...
}

Every billing operation now requires the caller to pass an authorizeReference callback that proves the current session is allowed to act on the given organization. Stripe's plugin handles this internally. Polar makes you build it. The first time we hit this in staging, it took half a day to trace why a logged-in user could query another org's subscriptions. If you adopt Polar without this layer, assume your billing endpoints are unauthorized until you add it.

Listing Subscriptions: Local DB vs Remote API

Subtle but operationally important. Stripe's plugin syncs subscriptions to your database via webhooks, so listing is a local query:

// packages/billing/stripe/src/stripe-provider.ts
async listSubscriptions(params: ListSubscriptionsParams) {
  const data = await db
    .select()
    .from(subscription)
    .where(/* ... */);
  // ...
}

Polar has no equivalent sync. Every list call hits Polar's API:

// packages/billing/polar/src/polar-provider.ts
async listSubscriptions(params: ListSubscriptionsParams) {
  const polar = await this.getProviderClient();
  const result = await polar.subscriptions.list({
    metadata: { referenceId },
    active: true,
    limit: params.limit ?? 10,
  });
  // ...
}

Implication for your app: every billing page load on Polar is a network round-trip to polar.sh. Plan caching at the route or query layer accordingly. With Stripe you can render the billing page from your own database with sub-millisecond latency.

Subscription Updates: Per-Item vs Flat

Stripe subscriptions can have multiple items (base price + per-seat price + per-feature price). To change a seat count, you find the right item by priceId and update it:

// packages/billing/stripe/src/stripe-provider.ts
async updateSubscription(params: UpdateSubscriptionParams) {
  const stripeSub = await stripe.subscriptions.retrieve(params.subscriptionId);
  const item = this.findSubscriptionItem(stripeSub, params.priceId);
  if (!item) {
    throw new Error(
      params.priceId
        ? `Subscription item with price ${params.priceId} not found`
        : 'No subscription items found'
    );
  }
  const updatedItem = await stripe.subscriptionItems.update(item.id, {
    quantity: params.quantity,
    proration_behavior: this.mapProrationBehavior(params.prorationBehavior),
  });
  // ...
}

Polar treats seats as a property of the subscription, not an item:

// packages/billing/polar/src/polar-provider.ts
async updateSubscription(params: UpdateSubscriptionParams) {
  const updated = await polar.subscriptions.update({
    id: params.subscriptionId,
    subscriptionUpdate: {
      seats: params.quantity,
      ...(prorationBehavior && { prorationBehavior }),
    },
  });
  // ...
}

It's a simpler API with less flexibility. The priceId parameter exists on the unified interface but is silently ignored for Polar because Polar doesn't have multi-item subscriptions to disambiguate.

There's also a quiet difference in proration: Stripe has three modes (create_prorations, none, always_invoice), Polar has two (prorate, invoice). Our Polar adapter maps Stripe's none to prorate because Polar has no equivalent to "don't prorate anything":

// packages/billing/polar/src/polar-provider.ts
case 'none':
  // Polar doesn't have a "none" option, default to prorate
  return 'prorate';

If your billing UX assumes "off" is a valid proration mode (e.g., for grandfathered plan changes), this is a behavior shift to plan for.

Usage Meters: Billing Periods vs All-Time

For usage-based billing, Stripe accepts a time range:

// packages/billing/stripe/src/stripe-provider.ts
const result = await stripe.billing.meters.listEventSummaries(params.meterId, {
  customer: params.referenceId,
  start_time: Math.floor(startTime.getTime() / 1000),
  end_time: Math.floor(endTime.getTime() / 1000),
});

Polar does not. Our adapter explicitly returns null for the time bounds to make the difference loud:

// packages/billing/polar/src/polar-provider.ts
return [{
  meterId: meter.meterId,
  customerId: params.referenceId,
  aggregatedValue: meter.consumedUnits,
  // Polar API doesn't support time range filtering
  // Return null to indicate all-time usage data
  startTime: null,
  endTime: null,
}];

If your product needs accurate "usage this billing period" aggregation (and most usage-based products do), Stripe is currently the only option of the two. With Polar you'd have to track period boundaries yourself in your database.

Entitlements: Native vs Build-Your-Own

Stripe's Entitlements API gives you boolean feature flags tied to subscription tier without a separate table:

// packages/billing/stripe/src/stripe-provider.ts
async listEntitlements(customerId: string) {
  const result = await stripe.entitlements.activeEntitlements.list({
    customer: customerId,
  });
  return result.data.map((entitlement) => ({
    id: entitlement.id,
    featureId: typeof entitlement.feature === 'string'
      ? entitlement.feature
      : entitlement.feature.id,
    lookupKey: entitlement.lookup_key,
  }));
}

Polar doesn't support entitlements. Our adapter throws:

// packages/billing/polar/src/polar-provider.ts
async listEntitlements(_: string): Promise<Entitlement[]> {
  throw new Error('Entitlements are not supported by Polar provider');
}

For products where features are gated by plan ("Pro gets advanced analytics, Free doesn't"), Stripe lets you express that in the dashboard and check it at runtime. With Polar you maintain your own mapping table and check against the active subscription's product slug. Workable, but it's a piece of infrastructure you have to build.

Pricing Math at Scale

This is the section that matters more than any feature comparison. Real cost differs significantly depending on geography and average transaction value. Approximate numbers across all three options:

On headline fees alone, Stripe Direct is the cheapest at every tier, then Polar, then Stripe Managed Payments by a wide margin. Managed Payments is roughly 2× Stripe Direct because the 3.5% MoR fee stacks on top of standard processing. On international cards with currency conversion, Managed Payments routinely exceeds 8% all-in.

The math flips when you factor in compliance.

If you sell internationally and are above EU VAT thresholds (€10,000/year in the EU is the simplified threshold for non-EU sellers), you have to:

• Register for EU VAT (or use the One-Stop-Shop scheme)
• Charge the correct VAT rate per country
• File quarterly returns
• Handle UK VAT separately (post-Brexit)
• Potentially handle India GST, Australia GST, Norway VAT, and more depending on customer geography

Stripe Tax helps automate the calculation (0.5% per transaction), but you still own filing, registration, and the legal exposure. The fully-loaded cost of compliance for a small team often exceeds the 1.1% fee delta between Stripe Direct and Polar's MoR. Polar absorbs all of that, and so does Stripe Managed Payments at roughly twice the headline fee.

The honest summary:

• Stripe Direct is cheapest if you're US-only B2B (or willing to own global compliance)
• Polar is cheapest-once-you-include-your-time if you sell globally to consumers
• Stripe Managed Payments is the priciest option, justified only when staying inside the Stripe ecosystem is worth more than the fee delta

What MakerKit Ships and Why

Both adapters live in packages/billing/{stripe,polar} of the Drizzle kit and the Prisma kit. The kit's Stripe adapter targets Stripe Direct via the standard Stripe Billing APIs through @better-auth/stripe. Because Stripe Managed Payments rides on top of those same APIs, the adapter can target a Managed Payments account with the same code path; the difference is on Stripe's side, not in your application.

The decision tree we actually use when helping customers pick:

• B2B with per-seat billing → Stripe Direct. Polar's single-product constraint forces awkward modeling; Managed Payments costs too much for high-volume B2B.
• Need feature entitlements out of the box → Stripe Direct.
• Need billing-period usage aggregation → Stripe Direct (Polar can't slice by time; Stripe themselves note Managed Payments isn't a good fit for sophisticated metered billing).
• Sell internationally to consumers → Polar. The VAT relief justifies the 1.1% delta over Stripe Direct, and Managed Payments costs 2× more for the same outcome.
• OSS monetization (sponsorships, license keys, GitHub-tied billing) → Polar. They've built for this case specifically.
• Indie product, single tier, want zero compliance work → Polar.
• Already deep on Stripe Billing, want MoR without re-platforming → Stripe Managed Payments. If you're shipping a simple subscription product and the fee delta isn't material, the zero-rebuild path is genuinely valuable.
• Sell to South Korea, China, India, Turkey, or Brazil with MoR → Polar. Managed Payments doesn't cover these markets.
• Migrating later might happen → Stripe Direct. Owning your subscription and customer records locally makes export trivial.
• You want the cleanest customer portal UX with zero theming work → Polar.

The fact that we ship both means we don't have to push the "right" answer. Customers pick the provider that fits their product, and the same kit code runs on either.

Migrating Between the Three

Honest assessment of migration cost across the three options:

Stripe Direct → Stripe Managed Payments. The easiest of the migrations because it isn't really a migration. It's a configuration change on your existing Stripe account. Customer records, subscriptions, payment methods all carry over. The catch: you need to be using Stripe Checkout (not Elements) and your country needs to be in the rollout list. There's also no clean way back if you change your mind without re-platforming.

Stripe Direct → Polar. Painful. You'd need to:

• Export customer records to Polar
• Re-collect payment methods (you can't move card tokens between providers)
• Cancel Stripe subscriptions and create Polar equivalents (customers will be re-billed at the next cycle)
• Re-engineer dunning and trial flows that you owned in Stripe
• Migrate your tax records if you were using Stripe Tax, or accept the discontinuity

Polar → Stripe Direct. Also painful, but less so:

• Polar's MoR model means tax records stay with Polar, so you start fresh on Stripe with no historical liability
• You still re-collect payment methods
• You gain back programmatic cancel/restore/plan-switch, so any feature parity gaps disappear

Polar → Stripe Managed Payments. Same friction as Polar → Stripe Direct plus the Managed Payments rollout constraints. Rare in practice.

In all directions, the actual blocker is re-collecting card details, not data export. Plan to email customers and absorb a churn bump on any migration involving a different processor. The exception is Stripe Direct ↔ Managed Payments, which is essentially a settings change.

Where to Go From Here

If you're picking a billing provider for a Next.js SaaS today, this comparison is one of several the decision usually depends on. The others:

• The full opinionated stack: The Best SaaS Stack in 2026 — our complete production pick (Next.js, Supabase, Drizzle, Better Auth, Stripe/Polar, Tailwind 4, Turborepo) with the same head-to-head format and receipts.
• The auth layer: Better Auth vs Clerk vs NextAuth vs Supabase Auth for the same kind of head-to-head with receipts.
• The ORM: Drizzle vs Prisma, the comparison that drove most of our customer ORM picks in 2026.
• The full stack guide: SaaS application development guide shows where billing fits alongside auth, multi-tenancy, and deployment.

Both the Drizzle kit and the Prisma kit ship Stripe and Polar adapters in production today. Switching providers is essentially a config change. That's the entire reason we built the unified BillingProvider interface in the first place.