When a WooCommerce order payment link says the order cannot be paid for, check who is signed in and who owns the order before changing the payment gateway. An administrator opening a customer's payment link is not the same test as that customer opening it.
Separate Access From Payment Processing
Record the exact message, the order's current payment state, whether it belongs to a registered customer or a guest, and the signed-in account used for the test. Do not include the full private payment URL or customer data in public screenshots or support tickets.
WooCommerce's order management documentation explains that a payment link for an order assigned to a customer requires the appropriate customer account. A different account, including an administrator's own session, can be rejected. Guest orders can have a separate email-verification step. These are access controls, not evidence that a card gateway is down.
Use a Safe Reproduction
On staging, create a test order with a test customer and the store's approved sandbox payment method. Generate the payment link through the supported order workflow. Compare the assigned customer's session, an unrelated account, and a logged-out session as appropriate.
Do not test with a real customer's password. For production, ask the customer to follow the login or verification flow themselves and provide only the non-sensitive error text. Never ask them to send a card number, login credential, or full payment URL in a public message.
Protect: Do not expose full private payment URLs. Sandbox: Use a test customer and test order. Boundary: Correct account allowed, others blocked. No duplicate charge: Separate access tests from payment tests. Explanatory checklist, not a customer test result.
Check the Order Before the Gateway
| Question |
Why it matters |
| Is this the intended order? |
A forwarded or older email can point elsewhere |
| Which customer is assigned? |
Access must match the intended owner |
| Does the order still need payment? |
Already-paid or unsuitable states need a different action |
| Is guest verification being requested? |
Complete the legitimate verification flow |
| Does the payment form load? |
Only then investigate method availability or gateway errors |
Review order notes and the current state without editing them merely to bypass the message. Reassigning an order to another account changes ownership and can expose private order information. Make such a correction only after verifying the real business record and the authorized customer.
For guest verification specifically, use our guest order email-verification guide. Guest access, logged-in ownership, and gateway eligibility should be diagnosed separately.
Look for Session and Cache Interference
If the correct customer still fails, reproduce in a fresh session and check for redirects between login, account, and order-payment pages. Confirm that the final session is the expected customer account. Review custom login or security extensions that alter the flow.
Use the store's established exclusions for private account and payment pages. Do not broadly cache customer-specific payment responses. If caching is suspected, capture the affected response and cache headers, then test a targeted configuration correction on staging.
Define Success Without Charging Twice
The access repair is proven when the authorized customer reaches the correct payable order and an unrelated account remains blocked. Gateway testing is a separate sandbox step. Never repeatedly submit a live order to see whether an access change worked.
If the form loads but no payment method is available, collect that new error and investigate order eligibility and gateway settings next. Request a focused WooCommerce fix with the redacted message, order state, and session test results so the repair preserves customer access boundaries.
References reviewed October 6, 2026. Examples are explanatory, not customer test results.