Orders and support

Where card authentication stopped

Read the provider payment reference in order: whether authentication was required, whether the buyer returned from it, the provider's payment status, and whether the store created an order. On Stripe, a PaymentIntent in requires_action still needs a step such as 3D Secure, and a failed authentication moves it to requires_payment_method. The store order, if one exists, is a separate record. Tell the integration team those statuses and references. Do not collect the card number, the security code, or the one-time code.

For: An owner or authorized representative of a research-use-only peptide business whose checkout shows a failed or unfinished card authentication.

Updated 2026-09-21

Four stops, not one failure

An authentication failure is not the same event as a decline after a normal authorization, and it is not a decision about whether the store should offer authentication. This page is only the journey you already observed. Split it into four questions: did the provider start an authentication step, did the buyer come back from that step, what status did the provider payment end in, and what order did the store keep?

A buyer who closes the page, a buyer who returns, and a payment that never leaves the provider can look the same in a support inbox. They are not the same stop. Write the reference for each one you can see, and leave the others blank.

What Stripe shows when the provider is Stripe

Stripe describes 3D Secure as a protocol that verifies the person making the purchase is the cardholder. The issuer may request a prompt such as a password, a one-time code, or a biometric check. Stripe says the issuer determines whether the flow is a challenge or a frictionless flow. Setting a preference for a challenge does not guarantee that flow.

Stripe's authentication flow says that when 3D Secure is required, the PaymentIntent moves to requires_action. If the result is authenticated, Stripe attempts the charge and the PaymentIntent moves to processing. If the result is a failure, the PaymentIntent moves to requires_payment_method, which means a different payment method is needed or 3D Secure can be retried by confirming again. A result of attempt_acknowledged can still lead to a charge, except in the Indian e-mandate case Stripe states separately. The payment then ends as succeeded, requires_capture, or requires_payment_method.

After a redirect, Stripe says to provide a return URL and, when the PaymentIntent is requires_action with a redirect, that 3D Secure is required. The integration then retrieves the PaymentIntent and reads its status. The Charge can also carry a three_d_secure result when the buyer attempted authentication. Stripe's Dashboard authentication chart uses separate outcomes: a successful frictionless flow, a successful challenge, a failed challenge where the buyer abandoned the flow or the bank rejected it, 3D Secure unavailable when the bank does not support it or returns an error, and 3D Secure not actioned when the buyer did not enter the flow or the integration did not action the attempt.

Stripe's payment-status page says requires_action is shown in the Dashboard as Incomplete, and that edge cases can change the mapping. The PaymentIntent status, read in the API or Workbench, is the more specific record. These names are Stripe's. Do not paste them onto another provider's dashboard.

What the integration team needs

The useful handoff is the provider payment identifier, the status at the stop you observed, whether a return from the authentication page was recorded, the authentication result if the provider shows one, and the store order identifier and status if an order exists. Say which checkout was live, the time, and whether the buyer saw a challenge or only a spinner, without asking the buyer to forward the challenge itself.

Do not ask anyone to paste a card number, a security code, a password, or a one-time code into email or the consultation form. The payment reference is enough to find the provider record. PCI DSS prohibits storing the card verification code after authorization, including in encrypted form. The one-time authentication code is not something the merchant diagnostic needs to keep.

If there is no PaymentIntent or charge yet, say that. Stripe's not-actioned outcome includes an integration that did not action the attempt. That is a question for the person who maintains the checkout, not a conclusion that the buyer's bank declined.

What you can close, and what stays unknown

You can decide which of the four stops you can document, and whether the store order agrees with the provider status. You can ask the integration team to trace that reference. You cannot decide, from a single failed challenge, that authentication should be removed, that the buyer is fraudulent, or that the issuer will explain the failure to you.

The issuer decides whether to challenge, whether the challenge succeeds, and what an authentication_required or other decline means on a later attempt. This page does not restate decline codes. The provider decides which authentication settings the account uses. Prism can discuss the checkout question in a consultation. That conversation does not change the provider account and does not establish that a payment will be authenticated next time.

Strong Customer Authentication rules may require 3D Secure in some regions Stripe names, and Stripe says 3D Secure is optional in others. Whether this business's payments fall under one of those rules is unknown from this page. Ask the provider against the actual account.

Authentication journey for one attempt

Complete this from the provider payment and the store order for the attempt you are diagnosing. Do not type a card number, security code, password, or one-time code. Worksheet entries are not submitted by this worksheet or saved by this site. Use only non-sensitive summaries; do not enter credentials, government identifiers, card or bank-account numbers, private receipt links, or customer details.

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.

Authentication journey for one attempt. The last column is for temporary notes.
Stop	What it tells the integration team	Where to read it	What you found
Provider payment reference	The team cannot trace a screenshot of an error without the payment identifier the provider assigned.	The provider payment, or the gateway note on the store order. Leave blank if no payment object exists.	Provider payment reference: What you found
Authentication required or not started	Stripe uses requires_action when a further step such as 3D Secure is still required. Not actioned can mean the buyer never entered the flow or the integration did not start it.	The PaymentIntent status and, if present, the Dashboard authentication outcome.	Authentication required or not started: What you found
Return from the challenge	A return URL lets the integration retrieve the PaymentIntent after the redirect. Loading the return page is not the same fact as the authentication result.	The integration log or the payment status after the buyer came back. Leave blank if there is no return record.	Return from the challenge: What you found
Authentication result	Stripe distinguishes an authenticated result, a failure, and other results such as attempt_acknowledged. The issuer chooses the flow.	The Charge three_d_secure result, if the provider populated it.	Authentication result: What you found
Final provider payment status	Stripe then shows succeeded, requires_capture, requires_payment_method, or another status. Incomplete in the Dashboard can hide more than one of those.	The provider payment status, preferably the PaymentIntent status rather than the summary label alone.	Final provider payment status: What you found
Store order result	The store may have no order, a pending order, or a failed order for the same attempt. That label is the store's record, not the issuer's result.	The store order list for the same time and reference.	Store order result: What you found

These are temporary notes. Leaving or reloading this page may clear them. The consultation form does not include these entries.

Limits

A Prism consultation can help you organize the facts and discuss the website or processing question. The payment provider decides eligibility, pricing, reserves, and whether an account is opened or closed.
Authentication statuses on this page are Stripe's. Another provider's challenge, return, and decline words are unknown until that provider's current document is read.
Nothing here shifts liability, removes authentication, or predicts whether the next attempt will succeed.
Do not send card numbers, security codes, one-time codes, passwords, or customer lists through the public consultation form.

Related guides

Sources checked 2026-09-21

3D Secure authentication — checked 2026-09-21. 3D Secure verifies that the purchaser is the cardholder. The issuer may request a password, one-time code, or biometric check. Stripe says 3D Secure might be required under Strong Customer Authentication in named regions and is optional in others.
Authenticate with 3D Secure — checked 2026-09-21. A required 3D Secure flow sets the PaymentIntent to requires_action. Authenticated leads to processing. Failure sets requires_payment_method. The issuer determines the flow. The Charge three_d_secure result records the outcome when the buyer attempts authentication.
Authentication analytics — checked 2026-09-21. Stripe's authentication outcomes include a successful frictionless flow, a successful challenge, a failed challenge, 3D Secure unavailable, and 3D Secure not actioned.
Payment status updates — checked 2026-09-21. The Dashboard payment status is a summary. requires_action maps to Incomplete and means more action, such as 3D Secure, is required. Edge cases can change the mapping, so the PaymentIntent status is the more specific record.
PCI SSC card-verification FAQ — checked 2026-09-21. Card verification codes are sensitive authentication data. PCI DSS Requirement 3.3.1.2 prohibits storing them after authorization, even if encrypted.
Prism contact — checked 2026-09-21. The consultation form asks for the website, products, and question. It says to leave out payment card details, passwords, and customer records. A request does not submit a processing application.

Request a consultation

Describe the business and this specific question. Prism follows up by email to discuss fit and scope. An inquiry is not a processing application or an approval.

Request a consultation All resources