Paddle for WordPress: Your Three Options in 2026

There is no official Paddle plugin in the WordPress directory. Search for “paddle wordpress” and you get a handful of third-party plugins and a lot of Paddle.js snippets. Behind that scatter there are only three ways to do it. Which one fits depends on a single question: where should the record of the sale live?

Option 1: a WooCommerce gateway plugin

If you run WooCommerce, or want a cart, a catalogue and an orders screen, add Paddle as a payment method. PimiPay is our paid plugin for this route. The customer places an order as normal, WooCommerce creates it as pending, and the Paddle checkout opens on the order-received page. When Paddle confirms payment through a webhook, the order completes.

Everything Paddle knows about the sale lands on the WooCommerce order: transaction ID, payment method, totals, and a link to the invoice. Refunds are issued from the order screen and sent to Paddle as adjustments. A refund made in the Paddle dashboard syncs back. Products sync from WooCommerce to Paddle, so prices are edited in one place.

The current limit is subscriptions. PimiPay handles one-time purchases only. If recurring billing is your business, read the next option.

Option 2: a membership or download plugin

The second route skips WooCommerce. Plugins in this class connect Paddle straight to WordPress user accounts. PaddlePress by HandyPlugins is the established example. The free version accepts payments, and the Pro version adds membership levels, content restriction, downloads, domain-based licence keys and subscription upgrades.

This is the right shape when the product is access rather than a catalogue: a members-only area, a course, a plugin sold with a licence. You give up the WooCommerce order model and its ecosystem. You gain a plugin built around subscriptions from day one.

Option 3: hand-wiring Paddle.js

The third route is what Paddle’s own docs teach. Include Paddle.js from Paddle’s CDN, initialise it with a client-side token, and call Paddle.Checkout.open() with a price ID. A button on any page opens the overlay checkout. It takes an afternoon and there is no plugin to buy.

Here is what breaks. Nothing in WordPress knows the sale happened. The checkout.completed event fires in the customer’s browser, and Paddle’s docs tell you to provision from webhooks, not from that event. Paddle Billing expects you to build fulfilment from transaction webhooks yourself, so you write an endpoint, verify the signature header, store the transaction, and grant access. Then a refund happens in the Paddle dashboard, and unless you also handle adjustment webhooks your site still says paid. Then a customer asks for their invoice and the only place to look is Paddle. You have rebuilt a gateway plugin, minus the parts that take longest.

For one product on a landing page, that trade can be fine. For a store, it never is.

The one thing all three must not do

Paddle is a merchant of record. It is the legal seller, so it calculates and collects tax at checkout, remits it, and issues the invoice and any credit note. That changes what the WordPress side is for. It must not calculate tax, must not generate its own invoices, and must not treat its own total as the truth. Its job is to record what Paddle decided and stay in sync when that changes. Our merchant of record guide explains why the liability sits where it does.

Choosing

If you sell through WooCommerce, take option 1. If you sell access and subscriptions, take option 2. If you have one product and a landing page, option 3 will do until the first refund. For the WooCommerce route, our guide to choosing a Paddle plugin lists the questions that matter, and the docs show exactly what PimiPay does.