Search Console shows an early click for the existing paid-but-pending PayPal guide at average position 6. A deeper technical cause is event sequencing: webhooks can be retried, duplicated, delayed, or delivered after the browser return, while WooCommerce hooks, stock, emails, and external systems react to each status change.
Use this for WooCommerce PayPal Payments stores where paid orders stay pending, move backward, send repeated emails, reduce stock twice, or disagree with PayPal and fulfillment records.
Quick answer
Create a sandbox order and record PayPal order ID, capture ID, webhook transmission ID, event type, create time, receive time, verification result, WooCommerce order version, and status transition. Replay the same verified event, delay a capture, and deliver an older event after a newer one. The handler must deduplicate immutable events, reject stale transitions, and reconcile from authoritative capture state.
What to check first
- Record WooCommerce and PayPal Payments versions, webhook registration, endpoint URL, verification configuration, order statuses, stock settings, email hooks, and connected ERP or fulfillment writers.
- Capture PayPal order ID, capture ID, transmission ID, event ID, event type, resource version, event creation time, receive time, verification result, HTTP response, and WooCommerce order notes.
- Test browser return before webhook, webhook before return, duplicate delivery, delayed capture, older event after newer event, network timeout after local commit, manual status edit, refund, and dispute.
- Compare payment complete time, transaction ID, order version, status, stock-reduced flag, email IDs, notes, webhook ledger, analytics, conversion tracking, and fulfillment export.
- Add a reconciliation job that checks paid PayPal captures against non-paid WooCommerce states without blindly replaying side effects.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Capture immutable PayPal identifiers | Record WooCommerce and PayPal Payments versions, webhook registration, endpoint URL, verification configuration, order statuses, stock settings, email hooks, and connected ERP or fulfillment writers. | Replaying the same event ID creates no new status, stock, email, note, or external action. |
| Persist a processed-event ledger | Capture PayPal order ID, capture ID, transmission ID, event ID, event type, resource version, event creation time, receive time, verification result, HTTP response, and WooCommerce order notes. | An older event cannot move an order backward over a newer capture or refund state. |
| Guard order status sequencing | Test browser return before webhook, webhook before return, duplicate delivery, delayed capture, older event after newer event, network timeout after local commit, manual status edit, refund, and dispute. | PayPal capture, WooCommerce transaction, order status, and order note agree. |
| Make side effects idempotent | Compare payment complete time, transaction ID, order version, status, stock-reduced flag, email IDs, notes, webhook ledger, analytics, conversion tracking, and fulfillment export. | The reconciliation job finds and assigns every paid-but-nonpaid mismatch without automatic duplicate effects. |
Why this usually happens
- Webhook delivery is at least once rather than exactly once.
- The sender can retry after the receiver committed but returned late.
- Browser return and webhook paths can race to update the same order.
- An older event can arrive after a newer capture or refund state.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wc_order_id: 91092
paypal_order_id: 8X...
capture_id: 4C...
webhook_event_id: WH-91
event_created: 10:00:02
received: 10:00:09
order_version: 184
transition: pending_to_processing
duplicate_replay_delta: 0
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Capture immutable PayPal identifiers
- Persist a processed-event ledger
- Guard order status sequencing
- Make side effects idempotent
- Run paid-versus-pending reconciliation
Decision rule
Pass when duplicate and stale events cannot repeat stock, email, fulfillment, or conversion side effects, while a verified authoritative capture moves the order to the intended paid state exactly once.
What to tell the client or owner
Give the owner the affected versions, exact workflow, observed result, business impact, evidence location, temporary control, named owner, and next review time. Remove credentials and personal data from shared screenshots and logs.
Production verification checklist
- Replaying the same event ID creates no new status, stock, email, note, or external action.
- An older event cannot move an order backward over a newer capture or refund state.
- PayPal capture, WooCommerce transaction, order status, and order note agree.
- The reconciliation job finds and assigns every paid-but-nonpaid mismatch without automatic duplicate effects.
Mistakes to avoid
- Do not change several plugins, cache rules, or infrastructure settings before preserving a baseline.
- Do not treat one successful test as proof for retries, alternate clients, background work, or mixed-version fleets.
- Do not paste secrets, personal data, complete production payloads, or customer files into tickets or screenshots.
- Do not close the test until the final user-visible state and the server-side evidence agree.
Questions teams ask during testing
Can HTTP 200 prove the webhook was applied?
No. It only confirms the endpoint response. Verify the processed-event ledger, order version, transaction ID, status, and side effects.
Should every event set the order status directly?
Prefer a version-aware transition derived from verified authoritative payment state and the store's documented order workflow.
When HandL WP should help
Bring in HandL WP when a production checkout, form, editor, security gate, media pipeline, or paid lead workflow is at risk. We can preserve evidence, isolate the failing layer, make the smallest corrective change, and verify the result across WordPress, connected services, logs, and the user journey.
If this is active on a production site, fix PayPal paid orders stuck pending.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references