What the failed-payment page should tell the buyer

Choose the message from the recorded outcome

Compare the exact text the store displayed with the order and the matching provider attempt. Keep the result, its known cause and the buyer's next action as separate parts of the message. A generic failure message may accurately describe an unsuccessful attempt while a sentence explaining why it failed is unsupported.

WooCommerce defines Failed as payment failing or being declined with no successful payment made. That is the store's recorded status. It is not proof that the gateway has no other attempt or that a previous attempt did not succeed. Pending payment and On hold are different states and should not be routed automatically to a definitive decline message.

This review concerns the store's native payment response. A hosted provider's success or cancel return address raises a separate question about session state. For native checkout, the integration owner should identify the provider outcome or verified internal error that selects each buyer message. If no such connection is established, preserve uncertainty in the wording instead of supplying a confident reason.

Issuer declines, provider blocks and request errors need different guidance

For a confirmed issuer decline, the message can state that the card payment was declined. Explain only the reason the provider makes available and permits the customer to see. Stripe notes that many declines do not reveal a specific reason and that issuers discuss the details only with their cardholders. A generic decline therefore does not support telling the buyer that their balance is too low or that they entered the wrong details. Where appropriate, direct the cardholder to their issuer for further information.

Make the action follow any returned advice. In Stripe's terminology, do_not_try_again means the same card should not be reused for that transaction. try_again_later permits a later attempt; confirm_card_data asks for correction. A universal retry button or instruction to keep trying can contradict the actual advice. If correction is supported, it should happen in the store's secure payment entry flow, never by sending card details to support.

For a provider-filter block, state that the payment could not be accepted through the current payment flow and offer the store's support route. Do not blame the issuer when the provider did not obtain issuer authorization, and do not label the buyer fraudulent. Keep internal risk assessments and filtering detail within the authorized investigation. A store cannot promise that contacting support will reverse the block or approve another attempt.

For a confirmed integration or invalid-request error, explain that checkout could not complete the payment request and give a support path. Do not ask the customer to fix a store-side request error by changing card data. Stripe says invalid API calls typically do not appear as payment records in its Dashboard. Absence there alone does not prove that every earlier attempt failed, so it does not justify a blanket no-charge assurance.

Unfinished authentication is not an invented decline reason

If the matching Stripe PaymentIntent is requires_action, the payment needs an additional action, which can include authentication. The buyer message should identify the outstanding step that the integration actually offers. It should not call the card invalid or say the bank declined it merely because the buyer did not finish the step.

Stripe distinguishes requires_confirmation from requires_action. Payment details ready for confirmation are not necessarily waiting for a bank challenge. Likewise, processing can mean an asynchronous payment is still underway, and requires_capture belongs to separate authorization and capture. None of those states supports a generic instruction to start payment again.

Review the visible action alongside the sentence. If the message tells the buyer to complete authentication but the store offers no functioning route to that step, retain a support route and assign the integration problem to its owner. The wording should not promise that authenticating will guarantee payment success. Use the actual provider and integration vocabulary; Stripe's status names do not govern another provider.

Answer the charge question without guessing

A buyer needs to know whether to act again. Before the page claims that no payment was taken, its information must be sufficient to establish that claim for the relevant attempt. An order marked Failed, an error page or a missing confirmation email is not that evidence. If the system cannot establish the payment result, say that it has not been confirmed and ask the buyer to contact the store before submitting again.

Support should reconcile the order's payment reference with the gateway before answering whether the attempt created a charge or authorization. WooCommerce's troubleshooting guidance warns against retrying while a charge may exist. Keep a usable order or support reference on the message where one exists, and tell the buyer how to use the store's actual contact route. Do not ask for a full card number, security code, authentication code or account password.

Review the current failure messages with this worksheet, using real recorded cases already available. Mark a branch unverified if no evidence shows what selects it. Decide whether the defect is unsupported wording, a wrong action for a known result, or a missing connection between the provider result and the message. That decision defines the next task without creating another payment attempt.

For a Prism checkout-review consultation, summarize the message and the documented outcome it contradicts. The related checkout-review service explains how to scope the work; confirm responsibilities, fees and terms before changes begin. A revised sentence cannot determine provider eligibility or guarantee that the next payment succeeds.

Failed-payment message check

Compare each applicable row with the exact message your native checkout currently shows. In the blank column record the current wording, the evidence that selects it, and the correction needed. This is a review of real messages, not a set of assumed payment outcomes. If the selecting evidence is absent, mark it unverified and keep the charge result uncertain.

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.