If Razorpay shows a captured payment but WooCommerce still shows Pending payment, first match the payment to the exact order. Then inspect the gateway notification and the plugin's processing logs. Do not ask the customer to pay again or mark every pending order as completed.
This guide explains how to investigate a WooCommerce order pending after a Razorpay payment, recover affected orders, and check that the repair works. It is for Indian store owners and the developers supporting them.
Documentation checked on October 5, 2026. This is a documentation-based troubleshooting workflow, not a report of tests on your store. The example is hypothetical. Plugin versions and dashboard labels can differ.
First establish whether payment or order synchronisation failed
A customer's debit notification, a captured payment, and a fulfilled order describe different things. Razorpay defines authorized as a stage before capture; captured means payment is complete at the gateway. Settlement to the merchant follows its settlement schedule. See Razorpay's payment lifecycle.
| Evidence | What to investigate | Immediate action |
|---|---|---|
| Customer reports a debit; gateway status is unconfirmed | Find the matching payment and its current state | Check the merchant dashboard before requesting another payment |
| Razorpay: Authorized; WooCommerce: unpaid | Capture configuration and the payment's capture deadline | Review the payment with the account owner |
| Razorpay: Captured; WooCommerce: Pending payment | Notification delivery, validation and order mapping | Record the payment ID and trace the update |
| Razorpay: Captured; WooCommerce: Cancelled | Payment timing, cancellation history and available stock | Reconcile the order before fulfilling or refunding it |
| WooCommerce: Processing; customer has no email | Notification settings and email delivery | Do not change payment settings solely to fix an email |
In WooCommerce, Processing generally means paid and awaiting fulfilment; Completed means fulfilled. Orders containing only products that are both virtual and downloadable are an exception to the normal processing step. Eligible pending orders can also be cancelled when the configured stock-hold period expires. These distinctions are documented in WooCommerce's order status guide.
1. Build a record for one affected order
Start with one recent failure and, if available, one successful order from the same period. Record:
- WooCommerce order number and internal order ID if a numbering plugin changes the displayed number.
- Razorpay payment ID and Razorpay order ID.
- Amount, currency, current payment state and current WooCommerce status.
- Order creation, payment and webhook timestamps, with their time zones.
- WordPress, WooCommerce, PHP and Razorpay plugin versions.
- Recent changes: hosting migration, firewall rules, plugin updates or API-key changes.
Match identifiers, amount and currency together. Two customers can pay the same amount, so an amount-only match is weak evidence. Keep the WooCommerce ID and Razorpay ID in separate fields; they identify records in different systems.
Check the order notes first, then WooCommerce > Status > Logs for the gateway entries around the same timestamp. If logging was disabled, enabling it will help with a new controlled test, not reconstruct missing historical logs. WooCommerce explains this in its order troubleshooting documentation.
2. If the payment is only authorised, check capture
Inspect the payment action in the Razorpay plugin and the account's payment-capture settings. An intentional manual-capture workflow should not be changed casually during debugging. Ask the person responsible for payments whether this order should be captured or cancelled.
The dedicated Razorpay capture-settings documentation describes automatic and manual capture timeouts, with a maximum of three days from creation. Shorter configured timeouts can apply. Check the actual payment promptly; do not treat the maximum as a waiting recommendation.
If the payment is already captured, repeatedly changing capture settings does not explain why the store failed to record it. Continue with the notification investigation.
3. Verify the webhook configuration for your installed plugin
A webhook is a background message from Razorpay to your store. It can help update an order when the normal checkout return flow does not finish. Use the endpoint required by your installed integration, including its domain, HTTPS scheme, path and query string. Do not paste a callback URL from an unrelated tutorial.
Razorpay documents automatic webhook configuration from plugin version 3.5.0 onwards when credentials are saved. Open the webhook configuration in the merchant dashboard and verify the destination and enabled state. Keep Test mode connected to the test store and Live mode connected to production.
Do not assume every event updates every plugin version
The official pages are inconsistent about event lists: the integration guide lists payment.authorized, payment.captured, payment.failed and order.paid; the plugin FAQ describes automatic setup for payment.authorized and refund.created.
The official webhook handler on the master branch, inspected for this guide, includes a payment.authorized handler and an accepted-event list without payment.captured or order.paid. That branch is not proof of what your installed release contains.
Practical decision: preserve the configuration your integration needs, confirm that its supported payment event reaches the store, and ask Razorpay support to verify the event list for your exact release if the documentation conflicts. Merely adding an event in the dashboard does not add a handler to the plugin.
4. Separate delivery failure from processing failure
Open the relevant webhook's delivery history. Razorpay's webhook FAQ places log history under Developers > Webhooks; setup may appear under Account & Settings > Webhooks. Find the delivery tied to the affected payment.
Use this table to choose the next check. The response is a clue, not a complete diagnosis.
| Observed result | Check next | Evidence to request |
|---|---|---|
| No matching delivery | Account, mode, subscribed event and endpoint state | Event name and configuration active at the payment time |
| 401 or 403 | Authentication barriers, security rules and application rejection | Response body plus matching access and firewall logs |
| 301 or 302 | Whether the registered URL redirects before reaching the handler | Final destination and the plugin's intended endpoint |
| 404 | Endpoint spelling, routing and whether the plugin is active | Requested path and server access entry |
| 5xx, timeout or TLS failure | Application errors, server availability and TLS configuration | Timestamped server or PHP error details |
| 2xx; order unchanged | Signature validation, supported event, order mapping and queued processing | Plugin log connecting that event to that order |
A 200 response does not establish that the right order was updated. Similarly, opening the endpoint in a browser does not reproduce a signed webhook POST. Ask for a valid test event and follow it through to the order record.
If a firewall rule is responsible, have the hosting team make a narrowly scoped correction after checking the logs. Keep signature validation enabled. Avoid turning off site-wide protection to make one request succeed.
Razorpay documents retries for failed deliveries over 24 hours and disabling persistently failing webhooks. After fixing the cause, check whether the endpoint needs re-enabling. Its webhook best practices also warn that a slow response can cause another delivery even when the first request reached the application.
5. Check validation and processing without bypassing either
For a signature error, compare the configured webhook secret with the value the installed plugin actually uses. A webhook secret is not automatically the same as an API key secret. Coordinate any change at both ends and account for outstanding events.
For a custom integration, validation must use the raw request body. Rebuilding JSON before checking its signature can change the bytes being validated. Razorpay also documents duplicate deliveries and events arriving out of order in its validation and testing guide.
Once validation passes, ask the developer to trace the order lookup, any queued job and the final order update. A useful log should let them explain: which event arrived, which payment it referred to, which order it matched, and why processing completed or stopped. Avoid collecting full customer payloads when identifiers and error details are sufficient.
If this requires changes to checkout or integration code, review our WooCommerce development and payment integration services. Bring the evidence record so the discussion starts with a reproducible problem.
6. Reconcile orders that were already affected
Fixing the delivery path and repairing historical records are separate tasks. Keep a reconciliation list with one row per affected order and an owner for each unresolved item.
- Confirm the current payment: match the gateway account, mode, payment ID, order ID, amount and currency. Check for a refund or duplicate payment.
- Review the store history: was the order cancelled, already fulfilled or changed manually? If stock was released, confirm availability before promising dispatch.
- Choose the recovery route: use a supported retry or replay for an eligible missed event, or have support reconcile the order through the appropriate WooCommerce workflow.
- Record the outcome: verify payment reference, order status, stock, customer notification and fulfilment tasks. Add a private order note explaining the reconciliation.
Razorpay's dedicated replay documentation describes dashboard replay for unacknowledged events up to seven days old. Events already acknowledged with a 2xx response are excluded. Older events require support. Check the available dashboard options before planning a recovery batch.
That means “the webhook returned 200 but the plugin did nothing” may need application-level reconciliation. Replaying messages blindly is not a universal repair. Test recovery on one affected record first and verify that duplicate delivery cannot create duplicate fulfilment work.
Worked example: a Chennai clothing store
Suppose a customer buys a Rs 2,400 kurta. The store order is Pending payment and the matching Razorpay payment is Captured. The delivery history shows a 403 at 14:12 IST; the hosting log identifies a rule rejecting that exact request.
The hosting team corrects the rule for the verified endpoint. A controlled test then reaches the plugin and updates its matching order. For the older sale, the team checks replay eligibility, the current payment state and stock before recovery. It confirms that one order is ready for fulfilment and one customer notification is sent.
This hypothetical example proves nothing about your store's cause. Its purpose is to show the evidence required at each step. If your delivery returned 200, the investigation would follow a different branch.
7. Test the whole order journey before closing the issue
Use a staging environment with Test mode credentials for development. Prevent test orders from reaching real shipping, accounting or customer-notification workflows. Before restoring normal operation, agree with the owner how to verify the production path.
| Scenario | Pass condition |
|---|---|
| Successful test payment | Matching order records payment and enters the appropriate next state |
| Failed test payment | No paid fulfilment task is created |
| Checkout return interrupted | The supported notification or recovery path records the verified payment |
| Duplicate event in a controlled test | No duplicate dispatch, invoice or other downstream action |
| One historical order recovered | Payment reference, stock and customer communication reconcile |
| Production configuration reviewed | Live credentials, endpoint and monitoring belong to the production store |
Keep a dated record of the versions tested and the result of each check. Revisit this checklist after changing hosting, checkout extensions or payment integration settings.
A support handoff you can copy
Send this through the provider's private support channel, with sensitive values removed from screenshots:
Issue: Razorpay payment captured; matching WooCommerce order still pending.
First observed and time zone: [date and time].
Scope: [one order / intermittent / every order].
WooCommerce order ID: [ID]. Razorpay order ID: [ID]. Payment ID: [ID].
Amount and currency: [amount and currency].
Versions: [WordPress, WooCommerce, Razorpay plugin, PHP].
Webhook: [event, destination, delivery time, response code].
Relevant log finding: [redacted excerpt].
Recent changes: [change and time].
Recovery already attempted: [action and result].
If several customers report the same incident, assign one support owner and connect each conversation to the affected order list. Our small-business help desk comparison covers tools for organising that support queue.
Do not include live API secrets, passwords or payment-card details. Ask for confirmation of the supported event, endpoint and recovery method for the installed release.
Frequently asked questions
Why is a WooCommerce order pending after a successful Razorpay payment?
If the matching payment is captured, investigate whether the store received, validated and processed the notification. If the payment is only authorised, investigate capture first. A customer's success screen alone cannot identify the cause.
Should I enable payment.captured and order.paid?
Follow the configuration supported by your exact plugin release. Razorpay's documentation gives different event lists, so verify the installed handler or ask support. Adding events cannot compensate for a blocked endpoint or unsupported processing logic.
Can I manually change the order to Completed?
Do not use Completed merely to mean payment received. Confirm the matching payment, fulfilment state, stock and downstream actions first. Use the appropriate recovery workflow and retain a private reconciliation note.
Will increasing the stock-hold time fix the problem?
It changes how long eligible unpaid orders retain their reservation. It does not repair a notification, signature or order-mapping failure. Investigate the payment update independently.
Does a successful webhook delivery mean the issue is fixed?
No. Verify the resulting order record and downstream actions. A response code and an updated order are separate acceptance checks.
Your next step: trace one payment all the way to fulfilment
Select one affected order and complete the evidence record before changing settings. Establish where the update stops, repair that step, then reconcile older orders separately.
Need help tracing a recurring mismatch? Discuss your WooCommerce payment integration with Innovative Code Tech. Share the plugin versions, symptom and redacted delivery result so the scope can be assessed.
