Do you ask for passwords in the form?

No. The public form never requests access. Secure credentials are requested only after the scope and quote are approved.

Who reviews the incident?

The request goes to Jordi Ensenyat, founder of Code Barcelona and a WordPress specialist with more than 15 years of experience.

Is anything changed before the quote?

No. Visible symptoms and scope are reviewed first. Intervention begins after approval and with a rollback path prepared.

Do you work internationally?

Yes. WP Repair handles WordPress and WooCommerce incidents in English and Spanish through a remote service.

How to Trace a WooCommerce Payment Without Exposing Card Data

A payment investigation needs stable references and timestamps, not card numbers. WooCommerce, the gateway and the browser each record different parts of the transaction. Joining those records safely reveals where processing stopped without expanding access to sensitive data.

Never ask a customer to email a full card number, security code, payment token or screenshot containing them.

Define the minimum evidence

Start with WooCommerce order ID, approximate time with timezone, amount, currency, payment method and provider transaction or payment-intent ID. A customer email may help locate the order, but redact it from shared reports.

Use a unique test reference for controlled transactions. Do not reuse a real customer identity for reproduction.

Safe correlation record:
Order: 12345
Time: 2026-07-28 14:32 Europe/Madrid
Amount/currency: 10.00 EUR
Provider reference: redacted-safe transaction ID
Event IDs: evt_... where appropriate

Confirm the provider permits those identifiers to be shared with the intended support recipient.

Start from the WooCommerce order

Read private order notes in sequence. Record order creation, selected gateway, transaction ID, payment confirmation and later status changes.

Inspect WooCommerce > Status > Logs for the same time and order reference. Export only the relevant lines. Whole log files may contain other customers’ data and credentials accidentally written by extensions.

Do not enable public debug display. Production diagnostics belong in protected server logs with limited retention.

Match the provider object

Search the gateway dashboard using the stored transaction ID, merchant reference, order number, time and amount. Confirm whether the object is authorised, captured, failed, cancelled, disputed or refunded.

Do not use the last four card digits as the primary link; they are not unique. Never copy cardholder authentication data or full provider payloads into WooCommerce notes.

Record the provider’s event timeline and any decline/error code that is safe to retain.

Trace webhook delivery

Find webhook events associated with the payment object. Record event ID, creation time, delivery attempts, HTTP status and duration.

A timeout does not mean WooCommerce did nothing. Check order notes and server logs before replaying. A 2xx response proves acceptance at HTTP level, not necessarily that every downstream task completed.

Keep signing secrets and signature headers out of screenshots. They authenticate the provider and may enable forged requests if exposed.

Inspect browser and server requests

For a controlled reproduction, capture the checkout request status and response. Redact cookies, order keys, addresses, tokens and form fields before saving a network export.

Match request time with web server access and PHP error logs. A request ID from a reverse proxy or host is safer and more useful than copying the whole body.

Limit staff access to logs and delete diagnostic exports when the incident retention period ends.

Configure payment logging carefully

Use the gateway’s official debug mode only for the shortest necessary period. Check documentation for what it records and where the file is stored.

Custom diagnostic logging should use identifiers, state transitions and error classes:

wc_get_logger()->info(
    'Payment callback received',
    array( 'source' => 'gateway-diagnostic', 'order_id' => $order_id )
);

Do not log request bodies, API keys, bearer tokens or payment fields. Validate that $order_id exists before using it in production code.

Build a handoff timeline

Summarise what each system proves:

14:32 order created as Pending
14:33 provider captured transaction abc…
14:33 webhook returned 500
14:33 PHP fatal in documented gateway callback

This timeline supports a focused repair while remaining understandable to store staff and provider support.

Close the investigation responsibly

Reconcile the order and provider state, correct downstream stock or fulfilment once, and record the outcome in a private note. Rotate any credential accidentally exposed during diagnosis.

Verify the repair with a controlled transaction and confirm one order, one payment, one successful webhook and the correct customer email.

Recurring care should standardise redaction, log retention and gateway reconciliation. Good payment evidence is concise, traceable and deliberately free of data the technician does not need.