The same order asks the buyer to authenticate repeatedly

Follow the payment reference through each prompt

Start with the existing order and the buyer's sequence: when the prompt appeared, whether they returned to checkout, and when they pressed Pay again. Record the time zone and distinguish the buyer's recollection from timestamps in store or provider records. Do not ask for a recording of bank codes or the authentication screen's private contents.

For each event, find the linked provider payment object. On Stripe, compare the PaymentIntent identifier across events; keep any charge or authentication reference in its own field. A changing charge reference is not by itself evidence that a new PaymentIntent was created. Conversely, the same store order number does not establish that all attempts used one PaymentIntent. If the gateway notes omit a reference, mark the link unresolved instead of joining records solely because their amounts match.

Separate an unfinished action from a later attempt

Stripe's lifecycle distinguishes requires_confirmation, when confirmation is still needed, from requires_action, when a further action such as authentication is required. A failed payment attempt can return the PaymentIntent to requires_payment_method. Therefore, the same identifier can have a history containing both an earlier action request and a later failed attempt. Its current status does not reconstruct the entire sequence.

A repeated requires_action observation on the same reference supports investigating an unresolved action or how checkout resumes it. A recorded failure followed by a later confirmation on that reference supports investigating a subsequent attempt within the same payment flow. Different PaymentIntent identifiers establish separate payment objects; compare their creation times with actual retry times to see which events coincide. These are investigation branches, not proof that a browser refresh, plugin or issuer caused the repetition.

Keep canceled payments separate: Stripe says cancellation cannot be undone. Reusing a store order cannot reopen a canceled PaymentIntent. Do not infer that every new identifier is erroneous, since an earlier canceled payment and an authorized recovery can legitimately be different records.

Establish whether anything remains payable

Read the latest provider outcome for every payment linked to the order, including ones the store no longer displays as its current attempt. A completed payment, an authorization awaiting capture, a payment still processing and a failed attempt require different handling. Stripe's lifecycle allows asynchronous processing to take days; elapsed time alone is not evidence of failure. Authentication progress also does not establish what the store recorded as paid.

WooCommerce's troubleshooting guidance says to identify the gateway from the order or its notes and confirm that the first attempt created no charge before asking for another payment. A provider charge paired with an unchanged store order belongs in a store-to-provider reconciliation. A missing order note can indicate missing gateway communication; it is not evidence of no charge. Apply the same check across the repeated attempts before deciding that the order still needs payment.

Give the next owner a bounded question

Once the timeline is joined, state the unresolved question precisely: whether an existing action is being resumed, why a new payment object appeared at a retry, or why the store still invites payment after the provider recorded a charge. Keep the evidence pointers with the authorized integration owner. If records cannot establish which payment belongs to a prompt, say that the association remains unknown and pause another payment instruction.

For a Prism checkout-review consultation, describe the website, research-only products, platform and repeated-prompt pattern without attaching customer records. The consultation establishes the requested investigation, responsibilities, fees and terms before work. Follow-up is by email; a request does not book an appointment, buy implementation or submit a processing application.

Repeated-challenge timeline

Use one sheet for an actual order. In the event rows, record a chronological list with time zones and evidence pointers. Compare payment-object identities before counting attempts, then check all current outcomes. Missing links mean the payable state remains unresolved. Keep this internal; do not enter card data, codes, secrets or private payment URLs.

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.