What matters first: PayPal may show a completed transaction while the local order remains pending or on hold. The callback can be blocked, configured for another domain or rejected because receiver and currency details differ.
When PayPal says complete but WooCommerce does not
Transaction ID, receiver account and callback history provide the evidence for a safe status decision.
Capture the payment and callback evidence
- Record PayPal transaction ID, payer, receiver, amount, currency and order ID.
- Check PayPal callback or webhook delivery logs and response codes.
- Verify live/sandbox settings and the configured business account.
- Inspect WooCommerce gateway logs and order notes.
Check receiver and environment before code
- Callback blocked: Firewall, maintenance or basic auth prevents PayPal from reaching WordPress.
- Account mismatch: Payment went to an address different from the configured receiver.
- Mode mismatch: Sandbox and live credentials or endpoints are mixed.
- Order lookup failure: Custom prefixes, migrations or duplicate IDs prevent matching.
Restore the authentic callback path
- Restore the callback path and verify it accepts only authentic PayPal messages.
- Correct account and mode configuration.
- Reconcile each historical transaction before changing order state.
- Complete a controlled payment and refund test through the full flow.
Blocked callback or account mismatch?
If PayPal never reaches the callback endpoint, inspect firewall, maintenance and authentication layers. If the callback arrives but WooCommerce rejects it, compare receiver account, currency, amount and environment. A completed remote transaction is evidence of payment, but not enough on its own to justify changing the local order state.
If PayPal delivery is being rejected, use the same boundary checks described for WooCommerce webhooks returning 401 or 403. If the callback is accepted but the order remains inconsistent, payment-completed orders that remain failed are the safer reconciliation reference.
Never use the return URL as proof of payment
Do not trust query parameters on the return URL as proof of payment.
Reconcile a full PayPal lifecycle
- PayPal and WooCommerce reference the same transaction and amount.
- New orders update without manual intervention.
- Invalid or unmatched callbacks remain quarantined and logged.
Close the incident only after a controlled PayPal payment updates WooCommerce without manual intervention, unmatched callbacks remain rejected and logged, and the subsequent refund also reconciles in both systems.
WP REPAIR INCIDENT STANDARD
How to narrow the fault without guessing
Transaction ID, receiver account and callback history provide the evidence for a safe status decision.
Record PayPal transaction ID, payer, receiver, amount, currency and order ID.
Check PayPal callback or webhook delivery logs and response codes.
Verify live/sandbox settings and the configured business account.
Inspect WooCommerce gateway logs and order notes.
What must be verified
- PayPal and WooCommerce reference the same transaction and amount.
- New orders update without manual intervention.
- Invalid or unmatched callbacks remain quarantined and logged.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Can I trust the PayPal return URL's query parameters as proof the payment went through?+
No, this is explicitly warned against. Query parameters on the return URL are not proof of payment; the PayPal transaction ID, payer, receiver, amount and currency need to be checked directly against PayPal's records instead.
PayPal shows the transaction as completed but the order is still pending — what's the most overlooked cause?+
An account mismatch, where the payment went to a different receiver address than the one configured in WooCommerce's PayPal settings, is a distinct and easily overlooked cause separate from the callback simply being blocked by a firewall or maintenance mode.
Does mixing sandbox and live PayPal credentials produce this same symptom?+
Yes. A mode mismatch, where sandbox and live credentials or endpoints are mixed, is listed as one of the common causes, and verifying live/sandbox settings and the configured business account is one of the specific evidence-gathering steps before making any change.
If order IDs don't match between PayPal and WooCommerce, could that be a migration issue rather than a payment issue?+
Yes. Order lookup failure caused by custom order-number prefixes, past migrations or duplicate IDs can prevent WooCommerce from matching an otherwise valid PayPal callback to the correct order, which is a data-matching problem rather than a payment or authentication failure.