The customer presses Pay, the page waits and a receipt-shaped screen appears. Has the payment succeeded, or has the business merely received an attempt? If the answer is still uncertain, the interface should say so before the customer tries again.
A pending-payment page has a specific job: explain the known state, identify whether the customer needs to act and provide a reliable way to learn the final result. It should not congratulate someone on a completed purchase simply because they reached the end of checkout.
This is different from a declined card, where the payment attempt has a known failure result, and from the order-review step before submission. The examples below concern the interval after an attempt has been submitted but before the business can confidently describe its outcome.
Name the state you actually know
Stripe’s PaymentIntent lifecycle distinguishes states including additional customer action, processing, success and authorization awaiting capture. Some asynchronous payment methods can remain in processing before the result is known. These are provider-specific states, but the distinction matters wherever a checkout has more than an instant success-or-failure outcome.
Create a mapping from the payment system’s verified state to the customer-facing message. Do not treat the words “submitted,” “authorized” and “paid” as stylistic alternatives. They describe different facts.
The following is a proposed content model. “Request submitted” is an application-level observation, not a Stripe status name.
| What the business knows | Customer-facing meaning | Appropriate action |
|---|---|---|
| The request was submitted; result not yet available | The attempt is being checked | Wait or view status; avoid an unverified retry instruction |
| The payment requires customer action | The attempt needs a specific step to continue | Complete the supported authentication or payment step |
| The provider reports processing | The payment has not reached a final result | Explain the next update and any relevant expectation |
| Payment success is confirmed | Payment was received successfully | Show the receipt and the actual fulfillment next step |
| Failure is confirmed | The attempt did not complete successfully | Offer the supported recovery route |
If the business separately authorizes and captures payment, it needs copy for that arrangement too. An authorization should not be presented as a captured payment merely because both feel close to completion.
Make the page reflect a recorded result
The success-looking destination URL is not enough to establish success. Stripe’s fulfillment documentation explains that customers may pay and lose their connection before the landing page loads. Its delayed-payment flow also has later success or failure events. Arrival at a page and the payment result are separate observations.
The practical requirement is that the page display the state associated with the particular order or payment attempt. A reload should retrieve that state rather than replay a generic thank-you message. The system that records the result and the system that writes the customer notification should agree on what happened.
This does not require exposing processor terminology to buyers. “We’re waiting for confirmation of your bank payment” can be clearer than an internal status code. But the plain-language sentence must remain tied to an actual known condition.
If the status itself cannot be retrieved, say that the site cannot currently show the result. Do not label the payment failed simply because the status page has a network problem. That distinction is especially important before offering another payment action.
Give the customer a stable place to return
Imagine fictional order B-1842. The business has recorded the order details, and its payment provider reports that the bank payment is processing. A proposed message is:
Your payment is still processing. We have saved order B-1842 and are waiting for the payment result. You do not need to submit another payment now. Check this order-status page for the result.
That wording is appropriate only if the order really has been saved and no further customer action is required. Add a notification promise only when the business has a working notification process and the necessary contact details. If dispatch waits for payment confirmation, state that separately so the customer does not mistake the saved order for a shipped parcel.
The GOV.UK confirmation-page pattern recommends explaining what happens next, when to expect it and how to contact the service. It also considers people who return through a bookmarked page. A payment-status page needs the same practical continuity.
Keep a recognizable order reference and a contact route. If access to the status page expires, provide a supported way to recover the order view. Sending the customer back to an empty checkout invites them to interpret an access problem as a missing purchase.
Set expectations from the payment method
A card interaction and a bank-payment process can have different timelines. Use the expectation supported by the actual method and provider, together with the merchant’s operational process. Do not attach a universal “This will take a few seconds” promise to every pending state.
If the business can provide a useful expected range, explain what the range describes. Is it the time to receive the payment result, to begin fulfillment or to send a notification? Those are different events. A delivery promise should not start silently from a time the customer cannot identify.
Avoid a countdown unless it corresponds to a genuine process. When an invented timer reaches zero, the page creates a new failure without resolving the original uncertainty. A clear status and a credible next step are more useful than a constantly moving spinner with no explanation.
Give the customer a defined escalation route if the result takes longer than the business expects. That route should identify the order so support can investigate the existing attempt before advising any new payment.
Make retries depend on the actual outcome
The most dangerous ambiguous instruction is “Something went wrong. Try again.” It may describe a failed payment, a lost connection after success or an unavailable status response. Those conditions do not justify the same next action.
While a payment is genuinely processing, avoid presenting another Pay button as the default route. If the provider later confirms failure, show the supported recovery action with a clear explanation of what failed. If the result is unknown, prioritize checking the existing attempt.
A customer who returns in another tab or device should see the same recorded outcome, subject to the site’s normal access checks. The copy should not depend on whether a temporary browser session remembered the first click. Distinguish a completed payment from an order that still needs fulfillment so that an unshipped item does not accidentally look unpaid.
Review the transitions before release
Walk through a proposed journey in which the customer leaves during processing and returns after success. Then review one that ends in failure, one that requires action and one where the status service is temporarily unavailable. These are review scenarios, not claimed tests of a real checkout.
For each transition, ask what the headline says, which action is available and whether the notification tells the same story. A success email and a processing page may reflect a delayed update; the page needs a way to refresh its knowledge without encouraging another purchase.
Include pending attempts in the broader checkout-abandonment analysis with care. A person who leaves while a bank payment processes has not necessarily abandoned an unpaid cart. Follow the recorded payment outcome before deciding what that departure means.
The page is finished when it can explain uncertainty without making the customer responsible for resolving it through repeated payment attempts. A clear pending state is a legitimate outcome, provided the business carries it through to a reliable final answer.