Your Developer Asked for a WooCommerce Checkout HAR File: What Now?

Agree on the question and sharing boundary

A HAR, or HTTP Archive, is a browser network export. Depending on the browser and export options, it can include URLs, query strings, cookies, authorization headers, request payloads and response content. These may contain credentials, session tokens or customer information.

Synthetic field values do not make a HAR safe to share. Guest sessions still use session data. Staging may contain credentials, production integrations or copied customer records. A browser’s sanitized export option does not guarantee removal of every sensitive value.

Limit this investigation to one shipping-total recalculation before order submission. Confirm the diagnostic question, intended recipient and approved sharing channel first.

Capture one recalculation without losing earlier activity

Have the developer verify staging isolation: disable live payments and real fulfillment, isolate email, and disconnect outbound production integrations. Configure test shipping behavior that supports the reproduction. Record differences from production.

Use a fresh guest browser context, logged out of WordPress, with autofill prevented from supplying personal details. Do not enter payment information or select Place order.

Open developer tools and select Network before loading checkout. Browser labels vary. Confirm recording is active, leave the list unfiltered, and keep Preserve log off for this non-navigation test. Do not clear the list after checkout loads: earlier requests may still matter.

• Let initial checkout activity settle. If checkout already remains loading, record that condition separately and stop rather than adding a shipping change.
• Perform the shipping change once. Use that action as the trigger reference for relative timing.
• Observe the shipping choice, totals and loading indicator without refreshing or repeatedly clicking.
• Record the observation cutoff relative to the trigger, including which requests remain active.

Note the trigger and cutoff using the same clock with seconds. Compare request starts only if you can align the Network panel’s timing reference with those notes. Time since page load is not time since your click; mark uncertain relative timings unknown.

Keep cache and security settings unchanged during this run. If staging does not reproduce the problem, report that result and known differences rather than exporting a live shopper’s session.

Locate and transcribe the request metadata

Inspect requests starting around the trigger and any still active then. Timing makes a request a candidate, not a proven explanation for the spinner.

Select a candidate request. Its details and timing display usually provide the URL, method, status and timing. Transcribe only the reviewed path, never paste the full URL. If a value is unclear, record unknown rather than guessing.

Use these labels:

• Reference and timing: Assign Request A or Request B; record its start relative to the trigger. Label estimates approximate.
• Reviewed path: Omit the hostname and query string. Check path segments for identifiers or tokens; label redactions, or withhold the path if uncertain.
• Method: Record the displayed method.
• HTTP status / browser state: Separate any HTTP status from pending, failed or cancelled labels.
• Duration: Record the completed duration, or identifiable elapsed time at the cutoff for a pending request. Elapsed time is not a final duration.
• Visible behavior: Describe checkout during that interval.

Exclude headers, cookies, request bodies and response bodies from this initial packet. Avoid copying raw network screenshots, full rows or “Copy as cURL” output.

A successful HTTP status does not establish that totals updated correctly. Pending or failed requests do not establish their cause. If no candidate is visible, say so.

Build one reusable developer packet

The example below is entirely hypothetical, and /example/shipping-refresh is invented—not a WooCommerce endpoint to search for. Complete the environment fields and replace the example setup with your exact synthetic test values.

• Environment: Checkout type; WordPress and WooCommerce versions; theme name/version; relevant shipping and checkout-extension names/versions.
• Browser: Browser/version; device; viewport.
• Staging differences: Live payments and outbound integrations are disabled, and test shipping configuration is substituted. Add other differences; mark unverified details unknown.
• Setup: One synthetic test item, quantity one, a synthetic destination matching a test shipping zone, and shipping choices A and B with different configured charges.
• Steps and timing: Open checkout with A selected. Wait for initial activity to settle, retaining the Network list. Select B once: this is the trigger reference. End observation 20 seconds later: this is the observation cutoff. Do not submit an order.
• Expected: Checkout shows B’s configured shipping charge and leaves the loading state.
• Observed: B appears selected, but the previous shipping total and loading indicator remain at the cutoff.

Request A

• Reference and timing: Request A; starts approximately at the trigger reference.
• Reviewed path: /example/shipping-refresh.
• Method: POST.
• HTTP status / browser state: No HTTP status observed; pending.
• Duration: Approximately 20 seconds elapsed at the cutoff; final duration unknown.
• Visible behavior: B selected; previous shipping total and loading indicator remain.

Unknowns: Whether Request A controls the loading state, whether the server received it, its eventual outcome, and why totals did not update.

Twenty seconds is only this example’s observation window, not a recommended timeout or proof of failure. Omitting query strings and bodies can remove distinctions between operations; metadata alone may be insufficient.

Agree on the next investigation

Choose one route with the developer:

• Metadata is sufficient: Assign the next investigation and record the question it will answer.
• A specific detail is missing: Identify it, then agree on a targeted staging capture with defined start and stop points. Name an authorized reviewer to inspect URLs, headers, payloads and responses before transfer. Document redactions, recipients, restricted transfer, retention and deletion responsibilities for attachments and downloaded copies.
• Isolation or review cannot be completed: Pause collection or transfer and arrange developer-led staging preparation and inspection.

Do not assume a Network-panel filter limits an export’s contents. Never upload raw exports to public analyzers, public issue trackers or AI tools.

Before sending, complete these handoff checks. They do not certify an export as safe.