If you sell one product, a handful of services, or take donations, WooCommerce is considerably more machinery than you need. A hosted payment link, a lightweight payment plugin, or a form plugin with a payment add-on will do the job with a fraction of the database tables, the plugin surface, and the maintenance.
WooCommerce is a genuinely good e-commerce platform, and it is built for stores with catalogues, inventory, shipping, and tax rules. Installing that to sell a single ebook is a common and expensive mismatch. Here are the alternatives, ordered by how little they ask of you.
Table of contents
- What WooCommerce actually costs you
- Option 1: hosted payment links, the lightest possible thing
- Option 2: lightweight payment plugins
- Option 3: form plugins with payment add-ons
- Option 4: the API directly
- Choosing, and when to just use WooCommerce
- How this fits the rest of the stack
- FAQ
What WooCommerce actually costs you
Not the licence — it is free. The costs are operational and they are easy to underestimate.
- Database weight. It adds a dozen tables and stores products, orders, and sessions as post meta, which makes
wp_postmetagrow quickly and query slowly. - Session handling. Cart sessions make pages uncacheable for anyone with a cart, which undermines the full-page caching your site depends on.
- Plugin surface. A real store needs extensions for payments, shipping, tax, and subscriptions. Each is another update, another compatibility risk, and often another subscription.
- Update cadence. WooCommerce and its extensions update frequently, and extension incompatibility after a core update is a routine event.
- Attack surface. More code handling money means more to keep patched.
The honest summary: WooCommerce is worth it when you have a catalogue. Products with variants, stock levels, shipping zones, tax jurisdictions, coupons, and customers with order histories. If you have none of those, you are paying the whole cost for none of the benefit.
Option 1: hosted payment links, the lightest possible thing
Every major processor now offers hosted payment pages you create in their dashboard and link to. No plugin, no code, no PCI scope on your site.
- Stripe Payment Links — a URL per product or price. Supports one-off and recurring, coupons, quantity, and address collection.
- PayPal buttons — a snippet you paste, with the checkout hosted by PayPal.
- Paddle and Lemon Squeezy — merchant of record, meaning they handle VAT and sales tax registration and remittance for you.
- Square, Mollie, Razorpay and most regional processors offer equivalents.
<!-- The entire integration -->
<a class="button" href="https://buy.stripe.com/your_link_here">
Buy the course — £49
</a>The merchant-of-record option deserves attention if you sell digital goods internationally. EU VAT on digital sales applies from the first euro with no threshold, and handling it yourself means registering, collecting evidence of customer location, and filing returns. Paddle and Lemon Squeezy take a higher percentage and become the legal seller, which removes that entirely. For a small digital product that is usually the better trade.
The limitation: the checkout happens on the processor’s domain, so branding is limited and you do not control the flow. For most one-product cases that is fine.
Option 2: lightweight payment plugins
When you want the payment on your own page, several plugins do payments without the store.
- WP Simple Pay — Stripe-focused, form-based, handles one-off and subscriptions. Purpose-built for exactly this gap.
- Easy Digital Downloads — for digital products specifically. Lighter than WooCommerce, with file delivery and licence keys built in.
- GiveWP — donations, with recurring giving and receipting.
- SureCart — newer, keeps most data off your site by design, which reduces both database weight and risk.
What to check before choosing one:
- Does the card form use the processor’s hosted fields? It must. Card details should never touch your server — that is the difference between a trivial PCI questionnaire and a serious one.
- Does it handle webhooks? Payment confirmation must come from the processor’s webhook, not from the browser redirect. A user closing the tab after paying should still get their product.
- Where is customer data stored? Less on your site is better.
- Is it maintained? Payment code is the last place to run something abandoned.
The webhook question is the one that separates good plugins from bad ones. If the plugin only fulfils an order on redirect, a closed tab means a customer who paid and received nothing, and you will find out from a support email rather than from your logs.
Option 3: form plugins with payment add-ons
If you already run Gravity Forms, WPForms, Formidable, or Fluent Forms, they all have payment add-ons. For services, bookings, and custom quotes this is often the neatest fit — you already have conditional logic, calculations, and notifications.
It works well when payment is one step in a larger process: a booking form that collects details, calculates a price from the options chosen, takes a deposit, and emails a confirmation.
It works badly as a product catalogue. There is no inventory, no order management, and reporting is whatever the form plugin gives you.
Check whether the payment add-on is included or a paid tier. For several of these plugins the payment integration is the reason to upgrade, and the annual cost can exceed the processor’s fees on low volume.
Option 4: the API directly
For a developer, a direct integration is perhaps a hundred lines and gives you complete control. The pattern is: create a checkout session server-side, redirect the customer, fulfil on webhook.
// Create a Checkout Session -- server side, secret key from the environment
add_action( 'admin_post_nopriv_rb_checkout', 'rb_create_checkout' );
add_action( 'admin_post_rb_checkout', 'rb_create_checkout' );
function rb_create_checkout() {
check_admin_referer( 'rb_checkout' );
$response = wp_remote_post( 'https://api.stripe.com/v1/checkout/sessions', array(
'headers' => array(
'Authorization' => 'Bearer ' . getenv( 'STRIPE_SECRET_KEY' ),
),
'body' => array(
'mode' => 'payment',
'line_items[0][price]' => 'price_1234',
'line_items[0][quantity]' => 1,
'success_url' => home_url( '/thank-you/' ),
'cancel_url' => home_url( '/pricing/' ),
),
'timeout' => 15,
) );
if ( is_wp_error( $response ) ) {
wp_die( 'Payment provider unavailable. Please try again.' );
}
$session = json_decode( wp_remote_retrieve_body( $response ), true );
wp_redirect( $session['url'] );
exit;
}Then a webhook endpoint that verifies the signature and fulfils the order. The webhook is not optional — it is the only reliable confirmation that payment succeeded, because the browser redirect can be lost.
The secret key belongs in an environment variable, never in the database or a theme file. On RunxBuild that is the service’s environment variables — see the services documentation — which also means rotating the key does not require a code change.
Never write card details to your own server. Use the processor’s hosted checkout or their JavaScript elements, which keep card data in an iframe on their domain. Handling raw card numbers moves you into PCI DSS scope that no small site wants.
Choosing, and when to just use WooCommerce
- One product or a few fixed prices → hosted payment links. Nothing to install, nothing to maintain.
- Digital downloads with licences → Easy Digital Downloads or a merchant of record.
- Donations → a purpose-built donation plugin.
- Services, bookings, custom quotes → your existing form plugin with a payment add-on.
- Selling internationally as a small operation → merchant of record, so tax is their problem.
- A catalogue with variants, stock, shipping, and coupons → WooCommerce. This is what it is for.
The recurring theme: choose based on whether you need order management, not on whether you need to take money. Taking money is easy now. Managing products, stock, fulfilment, and customer histories is the hard part, and that is the part WooCommerce solves.
One practical note whichever you choose: a site taking payments should be on a plan with dedicated resources, not sharing a machine. A checkout that times out under load is worse than a slow blog by a wide margin — RunxBuild’s WordPress ladder starts at $3/month and autoscaling handles the spikes, which is the relevant feature when a campaign lands.
How this fits the rest of the stack
If you are not managing a catalogue, you do not need a store. A payment link solves the single-product case in about a minute, a lightweight plugin covers the middle ground, and a direct API integration gives a developer full control for roughly a hundred lines. Whatever you pick, fulfil on the webhook and keep card details off your server. If you are sizing WordPress hosting for a site that takes payments, the RunxBuild hosting calculator shows the plan and database as separate line items.
Useful related references:
- Python .replace(): Simple Method, Three Things Worth Knowing
- Linux Find Processor Info: lscpu, /proc/cpuinfo, nproc
- Linux Display Processor Information: lscpu, /proc/cpuinfo, dmidecode
- Services on RunxBuild
FAQ
Do I need WooCommerce to take payments on WordPress?
No. Hosted payment links from Stripe, PayPal, or similar need no plugin at all. Lightweight plugins and form-plugin payment add-ons cover the middle ground. WooCommerce earns its weight when you need product catalogues, stock, and shipping.
What is the simplest way to sell one product on WordPress?
A hosted payment link. Create it in your processor’s dashboard and add it as a normal link or button. There is no plugin to maintain and no card data touches your site.
Why does my payment plugin need webhooks?
Because the browser redirect after payment is unreliable — a customer who closes the tab has still paid. The processor’s webhook is the authoritative confirmation, and a plugin that fulfils only on redirect will lose orders.
What is a merchant of record and should I use one?
A merchant of record becomes the legal seller and handles VAT and sales tax registration and remittance for you. For small digital products sold internationally it is usually worth the higher percentage, since EU VAT on digital sales applies from the first sale.
Is it safe to handle card details on my own WordPress site?
No, and you should not. Use the processor’s hosted checkout or their JavaScript elements, which keep card data in an iframe on their domain. Accepting raw card numbers puts you in PCI DSS scope that no small site wants.