A slow submit response makes buyers click Pay again
The page should acknowledge the first submission, explain that its result is still being checked, and prevent another payment submission while that attempt remains unresolved. Preserve the existing order or payment reference so the store can retrieve its result. If the wait ends without an answer, show an unresolved status and a real support or status-check route rather than calling the payment failed or inviting another charge. A spinner ending is not evidence that no charge exists.
For: A research-only store owner investigating a Pay button that leaves buyers unsure whether their first click worked.
Acknowledge the action without claiming payment succeeded
For the implementer's brief, separate three observable states: the first action was received, the payment outcome is being retrieved, and a verified result is available. The buyer needs readable text identifying the current state, not only movement on a button. The waiting state should explain that another submission is unnecessary while the existing attempt is being checked. Do not show a completion percentage or expected finish time that the integration cannot substantiate.
Preserve the order summary and a safe reference the buyer can use if follow-up is needed. A provider reference may belong only in the merchant's authorized records; the buyer does not need an API key, client secret, or private payment URL. If the integration cannot confirm that submission reached the provider, the message should say the result is unconfirmed. It should not imply that a payment was accepted merely because the button reacted.
Record the unresolved interval before choosing a fix
Use an actual report and the available order, gateway, and application records. Record the first click time and time zone, when the waiting message appeared, whether Pay stayed available, and what message eventually replaced it. Label a buyer-reported time as reported rather than an exact server timestamp. Do not ask a buyer to repeat a live payment to reproduce the delay.
Identify the gateway associated with the order. WooCommerce's troubleshooting guidance directs merchants to the payment method and order notes, and says not to retry until the gateway shows the first attempt created no charge. Missing notes may mean a communication problem; they do not prove that nothing reached the provider. Keep an unknown provider outcome marked unknown even if the browser has timed out.
A second click is evidence about the interface. A second request, order, or charge is a different finding that needs its own record. This page concerns the gap before those outcomes are established. If two provider payments are found, move to payment reconciliation rather than treating a revised waiting message as resolution of the existing payments.
Pair visible repeat-action handling with request handling
Ask the implementer to explain both what the page does with repeated actions and what the server does with repeated requests. Temporarily disabling Pay addresses one visible route, but does not establish how a reload, a lost response, or another open page is handled. The required outcome is that recovery remains connected to the existing attempt while its status is unresolved. The implementation must identify that attempt without depending on the buyer remembering whether a click registered.
For Stripe API requests that use idempotency, the same key can return the saved result of the original request. A differently keyed request does not inherit that protection. Keys can be pruned after they are at least 24 hours old, and reuse after pruning creates a new request. Therefore, the statement that an integration uses idempotency is not evidence that every repeated checkout action is protected. Ask the implementer which operation and retry path it covers; keep raw keys and request payloads out of this worksheet.
Define what replaces the wait
The exit from the pending display should follow a verified outcome for the existing reference. If the outcome remains unavailable, retain an honest unresolved message and a working route for the team to check it. Do not automatically restore an invitation to pay because a display timer expired. Once the gateway confirms no charge, any further attempt still follows the method's and integration's applicable instructions; absence of a charge is not an instruction to ignore a provider's retry restriction.
Give the implementer the observed interval and require an explanation of how the same attempt survives a delayed response. Review the actual changed behavior and its linked records when evidence is available; do not call it fixed solely because a spinner was added. A Prism checkout consultation can discuss the storefront behavior and provider question. Describe the site, research-only products, platform, and unresolved state without customer records or secrets. Scope, responsibilities, fees, and terms are agreed before work; the inquiry itself buys no implementation and submits no processing application.
Submit-wait behavior map
Use one real unresolved submission. Keep references inside authorized records and enter only non-sensitive labels here. A blank or unknown provider result prevents a retry decision; it is not a failed payment. Compare the visible state with the existing attempt before specifying the next action.
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.
Submit-wait behavior map. The last column is for temporary notes.
Observation
Where to obtain it
Decision it informs
Your evidence and required behavior
First click time
Where to obtain itExisting report or application record, including time zone and whether the time is exact or approximate.
Decision it informsWhere the waiting interval begins and which server activity could belong to it.
Visible pending message
Where to obtain itRecorded checkout wording and when it appeared after the first action.
Decision it informsWhether the buyer could tell that an action was received without being told payment succeeded.
Repeat action possible
Where to obtain itExisting observation of Pay, keyboard submission, reload, or another open checkout page.
Decision it informsWhich route the implementer must examine; do not create another live attempt to fill this row.
Existing payment reference
Where to obtain itAuthorized store and gateway records; note a safe internal label and whether the match is confirmed.
Decision it informsWhether status recovery can use the first attempt instead of creating a new one.
Request retry handling
Where to obtain itImplementer's documented operation, idempotency coverage where applicable, and recovery path.
Decision it informsWhether repeated requests remain linked to the same operation; a disabled button alone does not answer this.
Final outcome
Where to obtain itMatching provider status, store status, and observed final page message with their times.
Decision it informsWhether the pending display ended on verified evidence or merely on a timer.
Unresolved handoff
Where to obtain itActual support or status-check route and the person responsible for checking the existing attempt.
Decision it informsHow the buyer receives a truthful next step when the result is still unavailable.
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.
Limits
A slow response does not establish a failed payment, a second order, or duplicate charges. Do not retry while the first charge remains uncertain.
WooCommerce troubleshooting and Stripe idempotency documentation describe their respective systems. They do not establish the behavior of every gateway or installed extension.
Do not collect card data, authentication codes, private payment links, client secrets, API keys, or customer records in the worksheet or consultation form. Technical functionality does not establish processing eligibility.
WooCommerce: Troubleshooting orders — checked 2026-09-21. Identify the gateway on the order or in its notes and do not retry until the gateway shows the first attempt created no charge. Missing notes may mean the gateway did not communicate; an unchanged status does not establish a cause.
Stripe idempotent requests — checked 2026-09-21. The same idempotency key returns the saved result of the original request. Differently keyed requests do not inherit that protection; keys can be pruned after at least 24 hours, and reuse after pruning creates a new request.
Prism solutions — checked 2026-09-21. Published support includes storefront review and help with provider website questions. Scope, fees, and terms are discussed before work; provider eligibility and account terms remain with the provider.
Prism contact — checked 2026-09-21. An inquiry describes the website, products, and question, excludes payment-card details, passwords, and customer records, and receives email follow-up. It does not purchase a service, book an appointment, or submit a processing application.