The card fields never become usable

Describe whether the entry surface ever became ready

A payment-method label can be present while the fields beneath it never become usable. Record separately whether the entry area appeared, whether a field could receive focus, whether a loading indicator remained and whether the buyer reached any submission step. A screenshot of the page structure without personal or payment information can preserve the symptom; it cannot show the bank's decision.

Use the real reported session or observe the page without entering card details or submitting a payment. Record when observation began and ended instead of describing a spinner as permanent. If another session worked, keep its device, time and page context separately. One working session does not erase the failed observation, and one failed session does not establish that every buyer is affected.

Preserve the error and the installed integration

Ask the site maintainer to preserve the relevant console message already present at the time of the failure, including its timestamp and the named script or component where available. Use a sanitized excerpt, not a full browser dump. Record that no error was captured when none is available; do not invent an error from the symptom. An error occurring beside a blank field is a lead to investigate, not a completed causal explanation.

Record the payment extension's exact name and installed version, the store platform, active theme and known checkout type. Include any documented change immediately preceding the observed failure, while keeping chronology separate from causation. The version list identifies which component documentation and support route apply; a theme or extension name in a log does not by itself prove that component is defective.

WooCommerce's checkout-not-loading guidance is for its Stripe integration. It describes missing or unresponsive card fields and endlessly loading checkout as commonly associated with plugin or theme conflicts. That is a reason to investigate compatibility against the installed setup. It does not prescribe a universal fix, establish a cache setting or justify switching off live controls based only on the symptom.

A request is not necessarily an authorization attempt

Have the maintainer classify any provider-related request already recorded for that session: what operation it concerned, whether a response was observed and whether it can be tied to a payment outcome. Merely seeing the provider's name in network activity does not establish that a card payment reached an issuer. Preserve only the sanitized operation, time, status and a safe internal reference; exclude request bodies, credentials, private URL tokens and payment data.

Stripe distinguishes issuer declines, blocked payments and invalid API calls. Invalid calls typically do not appear as payments in the Dashboard. Therefore, an empty payment search alone cannot prove that no request occurred. Conversely, a browser error does not prove that the bank declined a payment. When the observation covers only form loading, describe the payment outcome as unestablished.

If a matching real payment record contains an issuer outcome, preserve it as a separate fact and use the decline investigation for that attempt. If a request failed before a valid payment existed, the integration request needs investigation. If no request evidence was captured, the immediate gap is observation of the form-loading failure, not an explanation from the cardholder's bank.

Use the record to define the next investigation

The handoff should state the readiness failure, observation window, installed version, captured error and the limits of the request evidence. This lets the maintainer investigate the entry surface and any concrete compatibility or request defect without treating the report as a generic decline. Record the responsible person and the exact missing evidence they need. Do not ask the buyer to submit repeated payments to establish whether the fields load.

For a Prism checkout-review consultation, send the website, research-only products, platform and a non-sensitive summary of the unusable fields. Describe the diagnostic or implementation work requested so scope, responsibilities, fees and terms can be confirmed. Prism's published storefront and provider-question support does not itself establish a repair commitment or restoration time. The provider decides account eligibility. The inquiry receives email follow-up and is not a booking, service purchase or processing application.

Payment-form readiness record

Use one record per observed session without creating a new payment. Keep unavailable evidence marked as not captured. Compare the loading state, error and request timing before choosing an investigator; none of these rows alone names the cause or proves an issuer decision.

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.