An authorized payment failed when the store tried to capture it

Find the original authorization and its current state

Match the order to its provider payment using the references retained by the store. Record the provider and account context, original authorization time, amount and currency, and the current provider state. Read the existing payment again after the reported failure: a store notification and a provider record can describe different moments.

Stripe’s status guide distinguishes requires_capture from succeeded, processing, and requires_action. The Dashboard label is a summary, while the PaymentIntent status is more specific. Succeeded means the payment flow is complete; processing represents a pending asynchronous outcome; requires_action indicates a further action requirement. Those are not interchangeable with an uncaptured authorization. For another provider, use that provider’s documented vocabulary.

If the order cannot be tied to an existing authorization, the reported capture failure is not yet established as such. Resolve the reference gap first. A record for a different attempt on the same order does not tell you what happened to the authorization the store tried to capture.

Compare the deadline with the attempt time

Locate the capture deadline belonging to the authorization. In Stripe’s authorization-and-capture documentation, capture_before describes that deadline on the relevant charge. Record its timestamp and time zone alongside the capture attempt time. Do not substitute the order’s age, the promised dispatch date, or a capture window quoted for another integration.

A documented deadline earlier than the attempt is a concrete timing discrepancy to investigate. It does not establish every cause of the error or authorize an alternative payment. If the deadline cannot be retrieved, write unknown and identify who can obtain it. If the attempt preceded the deadline, the clock alone does not explain the failure; the result and capture history are still necessary.

Read the attempted operation and any previous capture

Ask the authorized integration maintainer for the existing capture-attempt record: time, target payment, requested amount and currency, and the provider’s response or a safe request reference. Keep the store’s displayed error in a separate field. If the request never reached the provider, or no result was retained, that is an integration evidence gap rather than a demonstrated cardholder decline. Do not include API credentials or raw sensitive payloads in the worksheet.

Inspect earlier capture entries before interpreting a remaining order balance as available authorized funds. Stripe documents that a default capture takes the authorized amount, while a smaller capture normally releases the remainder. Most payments permit one capture; retaining and capturing a remainder requires supported multicapture. Capturing more than the authorization is documented only for certain eligible online card payments. An increased order total or a partial shipment does not establish access to either capability.

These checks identify questions the records can answer: whether this request targeted the right payment, whether its timing or amount conflicts with the existing authorization, and whether a prior capture had already changed what remained available. They are not a list of causes to assign without evidence. Preserve the returned error wording and let the documented result constrain the diagnosis.

Decide from the reconciled payment, then coordinate the order

If the provider shows a completed payment despite the store’s error, reconcile the store record and captured amount before asking the customer to pay again. If it still shows requires_capture, that identifies an unresolved capture state, not permission to keep pressing Capture. If it shows another state, investigate that state through the provider’s supported process. A missing or ambiguous result remains unresolved until the account owner or integration maintainer establishes what happened.

Record whether fulfillment has started and who owns the release decision. Payment investigation must not silently erase an existing shipping commitment or treat a store status edit as a capture. Any retry, replacement payment, cancellation, or other account action requires the merchant’s authorization and the provider’s supported process for the actual payment.

For a Prism checkout-review consultation, summarize the platform, confirmed provider state, timing discrepancy if any, and the unanswered question. Refer to the related checkout-review service to agree scope, responsibilities, fees, and terms. A consultation does not promise capture recovery or decide whether the provider will support the business.

Authorization-to-capture record

Use one record for the original authorized payment and its attempted capture. Keep references inside authorized business records; send only a non-sensitive summary to a public inquiry. Missing provider results stay unresolved and do not justify another customer payment.

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.