Checkout reliability

Find the confirmation step after payment details were entered

On a Stripe PaymentIntent, requires_confirmation means payment information has been provided and the intent is ready to be confirmed. It does not establish a completed payment or an issuer decline. Match that exact object and observation time to the store order, then have the integration owner trace the confirmation step and its recorded result. Many integrations combine payment-detail submission with confirmation, so the status alone does not prove that a separate button is missing or identify the code responsible.

For: A research-only merchant whose checkout collected payment details but whose matching Stripe PaymentIntent remains at requires_confirmation.

Updated 2026-10-01

Get help with checkout

Confirm which object and moment the status describes

Read the status from the matching provider record rather than from the store's success sentence or an earlier screenshot. Record the PaymentIntent reference, the associated store order reference, and when the status was observed. If the references do not connect, resolve that association before diagnosing a confirmation problem.

Stripe's lifecycle documentation describes requires_confirmation as the stage after payment information is supplied and the intent is ready for confirmation. It also says most integrations submit that information as part of confirmation, so they skip a separately visible stage. A status captured during a progressing checkout and a status still present when an unfinished checkout is investigated are different observations. The documentation supplies no universal timeout that turns one into a diagnosed fault.

Check that the object is a PaymentIntent. A SetupIntent can use the same status words, but its purpose is to set up payment credentials without collecting a payment. Completing a setup does not establish that the associated store order has been paid.

Trace the handoff from the buyer's last completed step

Record the last step the buyer actually reported completing: entering details, submitting the checkout, or seeing a subsequent message. Keep a reported click distinct from a recorded request. Collect the visible error wording and time without capturing card fields or asking the buyer to send card details.

The implementation owner should compare that account of the journey with the integration's records for the same intent. The useful questions are whether the flow reached confirmation, whether a confirmation request was recorded, and what response or error followed. If no request appears in the available logs, describe that as missing evidence until log coverage is understood; it does not prove that no request was ever sent.

Locate the handoff in the actual installed integration. A platform extension and a custom checkout may put responsibility in different places. A missing request, a recorded request error, and a changed provider status lead to different next actions. Do not prescribe a new confirmation call merely because a screen contains the word incomplete; the owner must first establish what the current flow already did.

Keep confirmation separate from authentication and decline

requires_confirmation and requires_action name different stages. Stripe uses requires_action when an additional action, such as customer authentication, is needed. A customer who has supplied payment details has not necessarily reached that stage. Sending the buyer to the bank for an authentication problem is unsupported when the only fact available is that confirmation remains required.

Stripe documents that a failed payment attempt can return the PaymentIntent to requires_payment_method. That is a different observation from requires_confirmation, and the actual error history matters. Do not tell the buyer that the bank declined this payment unless the matching record supplies evidence for that statement.

A status is a view of the object at the time checked, not a complete history of the journey. If the object has moved to a different state by the time the implementer inspects it, use the new state and the recorded sequence. Preserve the earlier observation without treating it as the current result.

Resolve the unfinished step without inventing a paid order

Keep the order out of the paid path on the strength of this status alone. Entered details, a submitted form, or a success-looking page cannot establish that this PaymentIntent completed payment. Before asking the customer to start again or anyone to submit another attempt, reconcile the current provider record with the order and any related attempt records.

The implementation handoff should name the last confirmed step, the evidence gap or recorded error, and the owner able to inspect that step. Completion means the actual confirmation path and resulting payment state are accounted for, and the store represents that result accurately. If confirmation advances to an authentication or other pending stage, report that stage rather than announcing payment success.

For a Prism checkout consultation, provide the website, platform, research-only products, and a non-sensitive summary of the unfinished step. Keep logs containing customer records, card data, passwords, or secret values out of the public form. Confirm investigation and implementation responsibilities, fees, and terms before work. Email follow-up to an inquiry is not a booked appointment, purchased repair, or processing application.

Confirmation-step record

Complete this for one real order and its matching provider object. Use references and redacted observations, never raw request payloads or card details. The result should identify the last evidenced step and the next owner; leave any cause not established by the records unresolved.

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.

Confirmation-step record. The last column is for temporary notes.
Record item	Evidence to locate	What it establishes	Your observation
Order reference	The store order and its recorded provider association.	Identifies the order being investigated; a store status alone does not establish payment.	Order reference: Your observation
Provider object and reference	The matching Stripe object type and identifier.	Distinguishes a PaymentIntent collecting payment from a SetupIntent saving credentials.	Provider object and reference: Your observation
Payment status and time	Exact status and the time it was read from the provider record.	requires_confirmation identifies a confirmation stage; retain the observation time so stale evidence is recognizable.	Payment status and time: Your observation
Last completed UI step	The buyer's reported step, visible message, and associated time, with sensitive fields omitted.	Describes the observed journey without treating a reported click as proof of a confirmation request.	Last completed UI step: Your observation
Confirmation request evidence	Integration records tied to the same intent, including their coverage and timestamps.	Separates a recorded request from an unobserved handoff; missing logs do not by themselves prove no request occurred.	Confirmation request evidence: Your observation
Observed error or response	Redacted error wording or result connected to that request.	Supports a specific investigation without inventing an issuer decline or bank-authentication requirement.	Observed error or response: Your observation
Implementation owner	The responsible extension maintainer or implementer and the unresolved handoff.	Assigns who can inspect the actual confirmation path before another attempt is proposed.	Implementation owner: Your observation
Current outcome and order handling	The latest provider state compared with the store's message and paid-order handling.	Shows whether the flow completed or still requires another step; a changed status must be interpreted on its own terms.	Current outcome and order handling: Your observation

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

These status meanings concern Stripe PaymentIntents and SetupIntents. Another payment provider or object requires its own definitions.
requires_confirmation does not supply a failure cause, a universal timeout, an issuer-decline explanation, or evidence of processing eligibility.
Do not enter card details, security or authentication codes, client secrets, API keys, private payment links, or customer records in the worksheet or public consultation form.

Related guides

Sources

PaymentIntent and SetupIntent lifecycle — checked 2026-09-29. PaymentIntent requires_confirmation is the stage after payment information is supplied and is distinct from requires_action; most integrations combine information submission and confirmation. Failed payment attempts can return to requires_payment_method. SetupIntents save credentials without collecting payment.
Prism solutions — checked 2026-09-21. Prism offers storefront review, card-processing preparation, and help with a provider's website questions. Scope, fees, and terms are discussed before work; the provider decides eligibility and account terms.
Prism contact — checked 2026-09-21. The form asks for the website, products, and question, excludes payment card details, passwords, and customer records, and leads to email follow-up. A request does not book an appointment, purchase a service, or submit a processing application.

Get help with checkout

Is this happening on your own store?

Get help with checkout All resources