Checkout sends the buyer around a login loop

Separate the intended account requirement from the failure

WooCommerce’s Accounts and Privacy documentation treats guest checkout, login during checkout and account creation as separate controls. Enabling a login form does not answer whether guests may place the order; offering account creation does not show that an existing account signed in successfully. Record each setting independently, including when account creation is offered.

Compare those settings with the affected purchase and the merchant’s documented access requirements. WooCommerce states that subscription purchases still need an account. If the cart includes a feature requiring an account, guest checkout alone does not establish that the login step is unnecessary. This investigation concerns an existing path that fails to return the buyer to payment; deciding to remove an account requirement is a separate decision.

Locate the first repeated destination

Use the real buyer report and any existing authorized observations or logs to write the journey in order. Record the starting page, the sign-in page, the action taken, the page reached afterward and the point that returns to an earlier destination. Include the time and browser context. State whether each move happened automatically or after the buyer clicked a link. A destination seen only after a click does not by itself prove an automatic redirect loop.

Next, record the evidence of account recognition at each step. A submitted login form alone is not proof of successful sign-in. If the available record shows an account recognized on My Account but checkout asks for sign-in again, the disagreement is between those observations. If account recognition was never established, keep the authentication outcome unknown. If the buyer reaches an account page and no further redirection is observed, record a return-navigation problem rather than inventing a repeating sequence.

Compare the observed destination with the destination the store intended after sign-in. Ask the maintainer to identify which setting, extension or customization owns that return. Do not assume core WooCommerce owns a redirect merely because its page appears in the sequence. Keep raw logs and full private URLs in authorized systems; the worksheet needs sanitized hostnames, paths and observations, not passwords, session values or reset links.

Inspect dynamic-page exclusions without declaring a cause

WooCommerce’s caching guidance says Cart, Checkout and My Account must remain dynamic, and some caching tools already exclude them. It also documents that cached My Account content can cause reset loops. That is a specific documented possibility, especially when the observed sequence includes password reset; it is not a diagnosis of every account-navigation failure.

Compare the actual routes visited with the exclusions configured in the caching layers the site really uses. Record the route, the rule that covers it and the evidence available about the response. A rule for a different page path does not establish coverage of the path in the report. Equally, an exclusion already covering the affected path is a reason to keep investigating rather than repeatedly toggling the same setting.

The host or caching-plugin owner should identify any configuration-specific handling needed, including database session exclusions where applicable. Do not infer a universal login or payment-session timeout from a cookie duration. A targeted correction must follow the evidence and preserve necessary security controls; disabling all caching or all access controls does not explain which part failed.

Assign a bounded correction and a visible finish condition

Give the responsible maintainer the three account settings, the observed sequence, the intended return destination and any cache-rule mismatch. The open question should identify the first unsupported transition: whether sign-in succeeded, whether the return destination was wrong, or why the next page did not recognize the account. Do not route the problem to the payment provider solely because payment appears later in the journey. If the existing records show a separate payment attempt, preserve that record as a separate issue.

Define completion as the authorized buyer reaching the intended checkout after sign-in, retaining the correct cart context and required controls, without returning to the same sign-in step. Evidence of that navigation does not require placing a new order or making a payment. A page that loads only after removing a required control does not meet that finish condition.

For a Prism checkout-review consultation, summarize the platform, the failing transition and what the available observations establish. Ask to confirm the scope of configuration or implementation help and who may change the store. Responsibilities, fees and terms are agreed before work; the consultation itself does not diagnose the cause or authorize removal of account controls.

Sign-in redirect sequence

Use one documented buyer journey. Enter the observed order of pages and distinguish automatic redirects from clicks. Mark unavailable observations unknown. Keep credentials, cookies, reset tokens and full private query strings out of this worksheet.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.