WordPress SaaS Billing: Choosing Between Polar, WooCommerce, and Other Providers

Billing is where a WordPress SaaS stops being a demo and starts being a business. In a Website-as-a-Service (WaaS) built on GrabWP Tenancy, a visitor signs up, pays, and gets a provisioned tenant site without you touching anything. The question is not whether you need billing, it is which provider fits your market. This guide walks through what billing must do, then compares Polar.sh, WooCommerce, and regional adapters so you can choose without repainting yourself into a corner.

What Billing Must Do in a Self-Service WaaS

The core flow is short to describe and unforgiving to get wrong: signup, pay, provision. A prospect picks a plan, completes payment, and the system creates their isolated tenant site automatically. No manual steps, no support ticket, no waiting.

For that to be reliable, three things have to hold. First, provisioning must be idempotent. GrabWP finalizes provisioning through webhooks on a payment.received event, so a retried or duplicated webhook does not create a second tenant or double-charge logic. Second, the paid plan a customer selects has to map cleanly to whatever provider actually processes the money. Third, the whole thing has to keep working after the first sale: renewals, expiry, cancellations, and failed cards are the ordinary weather of a subscription business, not edge cases.

GrabWP treats billing as a pluggable registry rather than a single hardcoded gateway. That is the design decision that makes the rest of this article possible: you pick a provider per plan, and the registry handles the wiring.

Polar.sh: Hosted or Embedded Checkout for Global SaaS

Polar.sh is the built-in choice for global SaaS subscriptions. It gives you a hosted checkout that lives on Polar’s side, or an embedded checkout you drop into your own signup flow, depending on how much of the experience you want to keep on your domain.

Polar fits when your customers are international, pay by card, and expect a modern subscription checkout. You create a product in Polar, then map your GrabWP paid plan to that Polar Product ID. When a customer checks out, Polar handles the payment and fires the webhook that triggers provisioning. Because provisioning finalization is idempotent, the tenant site is created exactly once even if Polar retries the notification.

The hosted option is the fastest path to selling: less to build, less to maintain, and the payment surface is not your problem. The embedded option trades a little setup for a more seamless signup on your own site. Both feed the same provisioning pipeline.

WooCommerce: Self-Hosted Billing with Dynamic Plan Pricing

If you already run WooCommerce, or you want to keep billing entirely on your own infrastructure, the WooCommerce adapter handles self-hosted subscription billing. The advantage here is control and dynamic plan pricing: your prices live in your store, under your rules, with your tax and coupon logic.

This suits operators who want checkout, invoicing, and customer records inside WordPress rather than a third-party dashboard. WooCommerce plans do not need a Polar Product ID at all, because the WooCommerce adapter validates its own mapping. You configure the plan against your store, and at checkout the adapter confirms the link is valid before taking payment.

WooCommerce asks more of you operationally. You own the payment gateway keys, the plugin updates, and the store maintenance. In exchange you keep the money flow and the customer data on your side, which some businesses and some jurisdictions strongly prefer.

Regional and Alternative Providers via the Adapter Registry

Global card processors do not cover every market. Plenty of customers pay by local bank transfer, and a checkout that ignores that loses real revenue. This is where the adapter registry earns its keep.

SePay ships as a separate adapter plugin, not as core code. It handles Vietnamese bank transfer over VietQR and hooks into the same billing registry that Polar and WooCommerce use. Installing it adds a provider option without changing how plans or provisioning work. The customer scans a QR code, pays from their banking app, and the confirmed payment drives the same provisioning flow.

The important part is the pattern, not the single example. Because billing is adapter-based, new providers can be added the same way. A Stripe billing adapter is in development, and the architecture is built so that additional processors can register without rewriting the checkout or the provisioning pipeline. You are not locked into the providers that happen to ship today.

Adapters also receive partner context during provisioning checkout. The partner system supports partner-scoped API keys and attribution, so resellers or affiliates can be tracked through the payment step rather than bolted on afterward.

Mapping Plans to Providers

The old constraint was that a paid plan was effectively tied to Polar. That is no longer true, and the change matters for anyone selling across multiple markets.

Creating or editing a paid plan does not require a Polar Product ID. You enter a Product ID only when you intend to sell that plan through Polar. For WooCommerce, SePay, or any other adapter, you leave it blank and configure the provider’s own mapping instead. A plan is a plan; the provider is a separate decision.

Validation happens per adapter, at checkout, not at plan creation. Each billing adapter checks its own mapping when a customer tries to buy. So a mis-mapped paid plan fails cleanly at purchase, on that one provider, instead of blocking you from creating or editing plans in the first place. You can build your full plan catalog, wire providers incrementally, and discover a bad mapping at the exact moment and place it matters rather than through a global error.

Practically, that means you can offer the same Pro plan at $9.99/month through Polar for international customers and through SePay for local bank transfer, each with its own validated mapping, without duplicating the plan.

Subscription Lifecycle: Expiry, Cancellation, and Payment Failures

A sale is the start, not the finish. GrabWP includes subscription lifecycle management covering the events that actually keep a SaaS honest: expiry, cancellation, and payment failures, backed by per-action history and an audit log so you can see what happened and when.

Expiry and backfill are handled as first-class actions, not manual database edits. When a subscription lapses, the system knows. Email notifications include payment-failure and subscription-cancellation messages, so a customer whose card was declined gets told, and an operator watching accounts is not guessing. Cancellation is an explicit action with its own record rather than a silent state change.

Because provisioning is idempotent and driven by webhooks, the lifecycle stays consistent even when providers retry events. The audit log gives you the trail to answer support questions and reconcile against the provider’s own records.

Choosing Without Regret

Pick Polar for fast, global, card-based SaaS subscriptions with hosted or embedded checkout. Pick WooCommerce when you want self-hosted control and dynamic pricing inside WordPress. Add SePay or another regional adapter when your customers pay locally. Because plans are decoupled from providers and each adapter validates itself at checkout, none of these choices are permanent, and you can run several at once.

GrabWP Tenancy is in guided beta, so we would rather set honest expectations than oversell. The billing registry, the built-in Polar and WooCommerce adapters, the SePay plugin, and the lifecycle tooling are real today; the Stripe adapter is on the way.

If you are planning the business side of a WordPress SaaS, start with the flow, not the gateway. See how signup-to-provision fits together in our guide on how to build a WordPress SaaS with no code, grab the free GrabWP Tenancy plugin, and when you are ready to sell, explore the full WaaS platform.