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.
What this symptom actually tells you
Transaction ID, receiver account and callback history provide the evidence for a safe status decision.
Capture evidence before changing anything
- 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.
Most common causes
- 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.
Safe diagnostic and repair sequence
- 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.
How to choose between the likely causes
Do not treat Callback blocked and Account mismatch as interchangeable. Firewall, maintenance or basic auth prevents PayPal from reaching WordPress. By contrast, payment went to an address different from the configured receiver. Use two checks to separate them: Record PayPal transaction ID, payer, receiver, amount, currency and order ID; and check PayPal callback or webhook delivery logs and response codes. Those observations usually show whether the next safe move is to restore the callback path and verify it accepts only authentic PayPal messages or to preserve the current state and widen the investigation.
On a live store, reproduce the issue with a controlled test order and follow the same payment, stock, tax and notification path used by customers. Avoid changing several checkout components at once because that changes the application state and can obscure the original sequence of events needed to attribute the failure. Record the exact timestamp, affected URL or transaction, last known good state and every change made during diagnosis. That handover is often what separates a repeatable repair from a temporary disappearance of the symptom.
What not to do
Do not trust query parameters on the return URL as proof of payment.
How to verify the repair
- PayPal and WooCommerce reference the same transaction and amount.
- New orders update without manual intervention.
- Invalid or unmatched callbacks remain quarantined and logged.
A visible symptom disappearing is not enough. Close the incident only when the original failing action, the surrounding business journey and the relevant logs all agree that the fault is gone.
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.