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
About this page
A guide to WooCommerce Integration, not a LILPE product claim
This page explains how it works and what to check. It doesn't say LILPE offers a WooCommerce plugin. Whether LILPE offers anything here, and through which regulated partner, is confirmed during onboarding.
Where LILPE fits
LILPE orchestrates the payments and payouts around it: one integration to the providers connected for your business, with routing, failover and reconciliation.
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.
| Compared on | 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 LILPE fits
This page doesn't say a LILPE plugin for WooCommerce exists or is published, and no payment method or fee is claimed. Whether LILPE 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 LILPE have a WooCommerce plugin?
This page doesn't say a LILPE plugin exists or is published. Whether LILPE can be used with a WooCommerce store, and how, is confirmed during onboarding.
Last reviewed . Examples, amounts and screens marked illustrative are not LILPE figures.
Guides
Guides and explainers
- E-commercePayment Gateway for E-commerce: How Online Store Payments Actually WorkBetween "Place order" and the money landing in your bank, an online store payment goes through checkout, authentication, a webhook, settlement and, sometimes, a refund. Here's the whole lifecycle from a store owner's side, what changes by payment method, hosted checkout versus API integration, and what to check before you choose a provider.Read the guide
- PlatformPayment Gateway Integration: Hosted Checkout, Redirect or API?There are four common ways to put a payment gateway into a website or app, from a redirect you can set up in an afternoon to a full API integration your developers own. How each one works, what it means for your security and PCI DSS scope, the steps every integration shares, and how to test before going live.Read the guide
- PlatformPayment Gateway Webhooks: Receive, Verify and Never Miss a Payment UpdateA webhook is how your payment provider tells your server that something happened: a payment succeeded, a refund went through, a payout failed. How webhooks differ from the return URL and the status API, how to verify signatures, why you must handle retries, duplicates and out-of-order events, and how to test it all.Read the guide
Get started
Talk to us about your setup
- 01Tell us what you needYour methods, markets and providers. We confirm what's available for your business.
- 02Sandbox accessTest credentials and the API reference, provided during onboarding.
- 03Integrate and testOne request pattern; run success, failure, refund and webhook flows in the sandbox.
- 04Go liveProduction credentials, with the LILPE team on hand for go-live.
Route every payment to where it succeeds.
Tell us which providers you use today and where payments get stuck. We'll show you what the setup would look like on LILPE.