Connect the delivered files to the release your store is running

Start with the destination that the merchant actually uses

Record the public site address and the specific affected page, along with the date, time and time zone of your observation. Identify which destination the release receipt names. A handoff can contain a valid source package while leaving unclear which site received it; a screenshot without an address and observation time does not resolve that uncertainty.

For WooCommerce, compare the WordPress address and site address in the system status report with the intended installation. The report also identifies the assigned cart and checkout pages. Use those fields to establish the installation and checkout under review. Do not assume that a URL in an old handoff or the first checkout page found in a page list is the page currently assigned.

Follow the receipt back to the delivered source

Ask for the actual release record from the person or system that performed the deployment. In your handoff, preserve the destination, deployment time, recorded outcome and the source revision or package identifier that the receipt actually names. A commit identifier can identify source; a package checksum can identify exact file bytes. Neither on its own says that those bytes reached the current site.

Compare that reference with the source delivered to the merchant. If the receipt names a different revision, keep both references and ask which one represents the deployed work. If no source identifier is recorded, the missing evidence is the relationship between the delivered files and the release. A later explanation may help locate the records, but naming a folder after a release date does not establish that relationship.

Use this as an evidence chain, not a prescribed hosting feature. A host, deployment service or implementer may retain different forms of receipts. Record only what exists, and make any manual deployment evidence explicit. If the available records cannot establish an exact source match, describe the handoff as identified only to that extent.

Compare configuration and versions as a separate layer

WooCommerce’s system status report lists the WooCommerce and WordPress versions, active plugins and their versions, the theme, template overrides, and the cart and checkout pages. Save the relevant non-sensitive inventory with its collection date. Compare it with the inventory expected for the named release. Separate active plugins from inactive ones when deciding which integration belongs in the current handoff.

A matching plugin version is useful evidence, but it does not identify every customization or setting. Use the implementer’s configuration record for the release’s relevant settings and custom changes, then compare those with the current authorized admin view. If settings have no formal version number, record their actual export or dated change record instead of inventing a configuration version.

A status report collected before the release cannot establish the installation afterward. A later plugin update or manual setting change can also make the current site differ from the original delivery. Keep the release inventory and current inventory distinct, naming any recorded later change. Do not silently replace the old record and lose the explanation for the difference.

State exactly what the comparison establishes

Record one conclusion for source identity and another for visible behavior. A receipt tied to the delivered source and matching inventory can establish a traceable release handoff within the records’ scope. The affected public page still needs its own dated observation. A visible correction can confirm the behavior you saw without proving every file matches; an exact source reference cannot prove every checkout operation works.

When a difference remains, name the missing receipt, conflicting revision, unmatched setting or affected URL and the owner who can resolve it. This page identifies the running release. Overall project acceptance, recovery capability and payment-provider eligibility remain separate questions.

For a Prism checkout consultation, give the site URL, observed behavior and a short description of the version discrepancy. The consultation defines pages, questions and follow-up before work, and the merchant decides which updates to make. Confirm scope, responsibilities, fees and terms. Do not paste a full system report, credentials or customer records into the public inquiry; it is not an implementation purchase or a processing application.

Visible-release identity

Complete this from the actual site, delivery and deployment records. Mark an absent reference as unknown. A source match requires a link through the release receipt; a version inventory or visible page alone cannot supply that missing link.

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.