WooCommerce · self-hosted store
Your store, your server, your payment plugin to look after
WooCommerce gives you control over everything, including the parts that break. Adding payments is a plugin install; keeping them working is updates, callbacks and the occasional conflict with another plugin. Plan for both.
- Your theme and checkout pageWhat the customer seesYou
- WooCommerceOrders, stock, the checkout logicYou update
- Payment gateway pluginTalks to the provider; receives its noticesYou update
- WordPress and other pluginsSecurity, caching, anything that can interfereYou update
- HostingServer, SSL certificate, uptimeYou or your host
- Payment providerPayment page, methods, settlementProvider
Two ways a plugin can take payment
Every gateway plugin does one of two things at checkout: sends the customer to the provider to pay, or shows payment fields on your own checkout page. Which one affects what your site has to secure, and how the checkout feels.
| Redirect to provider | Payment on your page | |
|---|---|---|
| Customer experience | Leaves your site briefly, then returns | Stays on your checkout |
| Card details | Entered on the provider's page | Entered in fields the provider hosts inside your page, or, riskier, sent through your server |
| Your security burden | Lower | Lower with provider-hosted fields; much higher if card data touches your server |
| Theme and plugin conflicts | Fewer | More, since your page renders the fields |
When paid orders stay “pending payment”
This is the classic WooCommerce payment problem. The customer paid, the provider knows, but your store never heard. The provider tells your site by calling a URL on it (a callback or webhook), and on a self-hosted site several things can get in the way.
Check the provider's dashboard for failed notices first: it usually shows the URL it tried and the response your site gave. That points straight at the cause.
| Cause | Fix |
|---|---|
| Security plugin or firewall blocks the provider | Allow the plugin's notice URL; check the firewall's log |
| Caching serves a stale page to the notice | Exclude the notice URL and checkout from caching |
| Site moved or URL changed | Update the notice URL in the provider's settings |
| SSL certificate expired | Renew it; many providers won't call an insecure URL |
| Maintenance mode was on | Allow notices through, or check orders placed during it |
Updates, conflicts and staging
A WooCommerce store is a set of moving parts that update on their own schedules. A payment plugin that worked last month can break after a WooCommerce update, a theme change or a new plugin that touches the checkout.
Keep a staging copy of the store, apply updates there first, and run a test payment before updating the live site. On a busy store, avoid updating on sale days.
Keep everything updated
WordPress, WooCommerce, theme, payment plugin: security fixes matter.
Test on staging
A test payment after every update to anything near checkout.
Few checkout plugins
Every plugin that changes checkout is a possible conflict.
Watch the logs
The payment plugin's log and your server's error log show problems early.
Test keys, live keys and the mistakes between them
Most providers give you two sets of credentials: test keys that simulate payments, and live keys that move real money. The plugin's settings decide which it uses. Many launch-day problems are simply the wrong keys in the wrong place.
Keep test keys on staging and live keys on production, never the reverse. When you copy the live site to staging, the live keys come with it, so switch them straight away, or staging test orders will charge real customers' cards.
Staging uses test keys. Always; check after every copy from live.
Live uses live keys. And test mode switched off in the plugin.
Notice URLs match the site. A staging URL in the live provider account loses real notices.
Keys rotated when people leave. Anyone who saw them shouldn't keep working credentials.
Designing the payment step of your checkout
Because WooCommerce lets you change the checkout, you can also make it worse. A few choices make the biggest difference to how many customers finish paying, especially on phones.
Order the methods
Put the method most of your customers use first, usually UPI.
Fewer fields
Remove checkout fields you don't need; each one costs completions.
Mobile first
Test on a mid-range phone on mobile data, not just a desktop on office Wi-Fi.
Clear failure messages
Tell the customer what happened and let them retry without re-entering everything.
Reconciling orders with settlements
WooCommerce records what each order was worth; your provider settles batches net of charges, refunds and chargebacks. Make sure the plugin sends your WooCommerce order number with each payment, so every settlement line can be traced to an order.
If you use accounting software, decide where the match happens: in WooCommerce, in the accounting system, or in a spreadsheet someone owns. What matters is that it happens on a schedule, not only when numbers look wrong.
| Check | Looks for |
|---|---|
| Paid orders vs provider payments | Orders marked paid without a payment, and the reverse |
| Pending orders older than a day | Missed notices |
| Refunds in WooCommerce vs provider | Refunds recorded but never sent |
| Settlement totals vs bank credits | Short or missing payouts |
A fast checkout is a paid checkout
On a self-hosted store, checkout speed is your responsibility, and it shows directly in how many customers finish paying. Heavy themes, page builders, chat widgets and tracking scripts all load on the checkout page unless you stop them.
Keep the checkout lean: load only what the payment step needs, exclude checkout from caching that breaks it, and test speed on a phone. Every script on the checkout is also one more thing that could be compromised to skim payment details.
Remove what checkout doesn't need. Chat widgets, sliders, extra tracking.
Cache carefully. Never cache checkout, cart or payment notice URLs.
Choose a light theme. Or at least a light checkout template.
Measure on a phone. On mobile data, where most customers are.
Subscriptions and saved cards on WooCommerce
Repeat billing on WooCommerce usually needs a subscriptions extension plus a gateway plugin that supports recurring payments with it. In India, card and UPI recurring payments run under RBI's e-mandate rules, and saved cards work only through tokens; your store never holds card numbers.
Check both halves before selling subscriptions: that the extension and the gateway plugin work together, and that the provider supports mandates for the methods your customers use. See subscription payments and card tokenisation.
Security basics for a store that takes payments
Because you run the server, securing it is your job. Attackers target online stores to inject code that skims card details at checkout, which is one more reason to keep card entry on provider-hosted pages or fields.
Plugins only from trusted sources. Never a 'free' copy of a paid plugin.
Strong admin access. Two-factor login for every administrator; remove old accounts.
API keys kept secret. Only in the plugin settings, never in a theme file or shared chat.
Backups. Tested restores, not just backups that exist.
Choosing a plugin you can live with
Who publishes it
The provider itself, not a third party you've never heard of.
How recently it was updated
And whether it's tested with current WooCommerce versions.
How it handles card data
Redirect or provider-hosted fields.
How notices work
And where you can see failed ones.
Refunds from the order screen
Whether a refund in WooCommerce reaches the provider.
Support
Who you call when checkout breaks on a Saturday.
Where Peneu fits
This page doesn't say a Peneu plugin for WooCommerce exists or is published, and no payment method or fee is claimed. Whether Peneu can be used with a WooCommerce store, and how, is confirmed during onboarding. Notices and callbacks in general: collection API handbook.
How do I add a payment method to WooCommerce?
By installing the payment provider's gateway plugin, entering the keys from your provider account in its settings, and enabling it under WooCommerce's payment settings. Install plugins only from the official WordPress plugin directory or the provider's own site.
Why do paid orders stay 'pending payment'?
Usually because the provider's notice (callback or webhook) isn't reaching your site: blocked by a security plugin or firewall, broken by a caching rule, or pointed at the wrong URL. The customer paid; your store just wasn't told.
Is it safer to redirect customers to the provider's page?
Redirect or provider-hosted payment fields keep card details off your server, which reduces what your own site has to protect. Taking card details directly on your pages brings much heavier security obligations. Ask each provider how its plugin handles card data.
Do I need to update the payment plugin?
Yes, promptly, along with WordPress and WooCommerce. Updates fix security issues and keep the plugin compatible. Test updates on a staging copy first if your store is busy.
Can a WooCommerce store save cards?
Not as full card numbers: in India, merchants and their payment aggregators can't store them. Saved cards work through network or issuer tokens handled by the provider. See the card tokenisation guide.
Can I run two payment plugins at once?
Yes, many stores offer two providers, for example one for UPI and one for international cards, or a second as a fallback. Each needs its own testing, and both should send order numbers so settlements can be reconciled.
What should I do if checkout breaks after an update?
Restore the previous version of whatever you updated (a staging copy and backups make this quick), check the payment plugin's log, and contact the plugin's publisher with the error. Don't leave a broken checkout live while you investigate.
Does WooCommerce itself charge for payments?
WooCommerce is open-source software you run yourself, so the payment charges come from your provider. Hosting, paid extensions and any paid version of a gateway plugin are separate costs to count.
What should I log to troubleshoot payments?
Turn on the payment plugin's own logging if it has it, keep your server's error logs, and note the provider's payment reference against each order. With those three, most payment problems can be traced in minutes instead of days.
Does Peneu have a WooCommerce plugin?
This page doesn't say a Peneu plugin exists or is published. Whether Peneu can be used with a WooCommerce store, and how, is confirmed during onboarding.
Last reviewed . Examples, amounts and screens marked illustrative are not Peneu figures.