A bot challenge is not the bank authentication step

Separate the prompts in the reported sequence

Ask for a description of each prompt, the time it appeared and what action immediately preceded it. Record whether it occurred on the store form, after opening the hosted payment page, or during an apparent bank-authentication step. Preserve the visible service name and non-sensitive error wording when available. Keep private checkout addresses, challenge tokens and personal information out of shared screenshots and the public inquiry.

Treat the buyer's phrase verification loop as a report, not a diagnosis. More than one control may appear during the same checkout journey. Two prompts with different wording or owners need separate entries even if the buyer experienced them as one interruption. An unfamiliar logo or a page's appearance is a clue to verify against integration records, not sufficient proof of ownership.

Use the documented purpose to classify the control

Stripe's hosted Checkout guide lists CAPTCHAs as a built-in feature and describes risk interventions that can add security. That provides a documented explanation for an anti-abuse control on a Stripe-hosted page. It does not prove that a particular buyer triggered a risk rule, that every prompt was issued by Stripe, or that the merchant can remove it with a local setting.

Stripe's 3D Secure documentation describes verification that the purchaser is the cardholder. The issuer may request a password, one-time code or biometric step and determines the final flow. A confirmed issuer authentication request therefore belongs to a different process from a CAPTCHA. Use the payment's recorded authentication details to corroborate the classification; do not ask the buyer to disclose the password, code or biometric information.

For a prompt on a merchant form, compare the page and installed integration records to establish who configured it and which service supplies it. Do not assign it to the issuer merely because it appeared near a payment button. If the records cannot distinguish merchant form control, hosted anti-abuse control and issuer authentication, retain an unresolved classification and identify the evidence still needed.

Pair the challenge with the payment that actually exists

Have an authorized team member find the matching provider payment and store order using their internal references and timestamps. Record the provider's exact current state and any documented authentication outcome separately from the store's status. If no matching payment was found, record where and when the search was made; absence from one search is not proof that no payment exists anywhere.

A challenge that disappeared, repeated or appeared to complete is an observation about the interface. Use the provider record to establish what happened to payment. Do not tell the buyer to submit again while the earlier payment state remains unresolved, and do not treat a store success message as the issuer's authentication result.

For repeated prompts, compare whether the internal session and payment references stayed the same or changed. The same reference with another prompt and a new reference created after another submission are different sequences for the owner to investigate. Neither sequence alone proves a browser defect, fraudulent behavior or the cause of a rejection.

Give the responsible owner a bounded question

A confirmed merchant form control goes to the site maintainer with its configuration and the observed stop. A confirmed hosted anti-abuse control goes to the relevant hosted-service support route with the permitted internal references and the visible symptom. A confirmed 3D Secure flow needs the payment provider or integration team to trace the recorded authentication stage; personal bank-authentication problems may require the cardholder to use the issuer's own support channel.

Keep the question specific: which control produced this prompt, which record establishes its outcome, and why did this checkout sequence return to it? Preserve the device and browser version as context if the buyer supplied them, but do not promise that changing browsers, clearing data or disabling protection will resolve it. Do not bypass a control to obtain a successful payment.

A Prism checkout-review consultation can begin with the identified control, checkout platform and unresolved handoff. Agree the review or implementation scope and responsibilities before work. The consultation does not operate an issuer challenge, guarantee recovery or establish that the provider approves this research-only business.

Challenge ownership record

Use one copy for one genuine reported sequence, recording separate observations for distinct prompts. A classification is confirmed only when visible evidence and the responsible system's records agree. Keep lookup references in authorized systems; never collect challenge answers or payment credentials.

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.