A successful Stripe SetupIntent does not establish payment. It saves payment credentials without creating a charge. Identify the completed object, then look for a separate payment record tied to the order and verify its status, amount and currency. A successful setup may coexist with a separate successful payment, but the setup itself supplies no collected amount. If setup is the only confirmed result, do not fulfill the order as paid or ask for another payment until the existing payment records have been reconciled.
For: A research-only store owner or operations lead investigating an order marked paid after a payment-method setup flow.
Stripe’s PaymentIntent and SetupIntent lifecycle documentation describes two different operations. A PaymentIntent manages collecting funds. A SetupIntent prepares payment credentials for future use without charging them. Both objects can reach a status called succeeded, so the status word alone does not identify what completed.
Open the provider record linked by the store’s order notes or integration record. Write down whether it is a SetupIntent or a PaymentIntent and the exact status it reports. A saved payment method, a completion message or a page saying success is insufficient to classify the order as paid. If the store only retained a reference to the saved method, record that limitation instead of treating it as a charge reference.
Authentication can also occur during setup. Stripe documents that setup may authenticate the payment method without charging it. The buyer completing an authentication step therefore does not resolve whether this order was paid.
Find the separate collection record for this order
Match the order with the provider account and the payment attempt the integration actually used. Look for an existing PaymentIntent and its associated charge record, if any, using the references held in the authorized store and provider systems. Compare the order amount and currency with the amount the provider actually collected. Merely finding another payment from the same customer does not tie it to this order.
A PaymentIntent’s existence is not enough either. Stripe documents requires_confirmation as a confirmation stage, requires_action as a further-action stage, processing as an unfinished stage for asynchronous payment methods, and requires_capture when funds have been authorized for later capture. Those states do not mean the same thing as succeeded. The lifecycle documentation says a succeeded PaymentIntent has completed that payment flow; the result belongs to that payment, not to every order associated with the saved method.
Keep two findings separate: the setup collected no payment, and the order may or may not have a separate payment. When a search is incomplete or a relevant account record is unavailable, the order’s collection status remains unknown. Do not record a confirmed zero for the whole order merely because the SetupIntent itself created no charge.
Choose the order action from the collection evidence
If only setup has been confirmed and no collection record has been verified, keep the paid-fulfillment decision open. Have the authorized record owner finish the reconciliation before requesting payment again. This avoids converting an incomplete investigation into a duplicate collection request.
If a separate payment is still awaiting confirmation, action, processing or capture, record that exact stage and assign the next step to the owner of that payment flow. A setup success cannot advance the separate payment. If the matching payment has succeeded for the expected amount and currency, record the payment reference as the basis for the order’s payment status, subject to any other existing fulfillment controls.
If the store already marked the order paid on setup alone, preserve the original order note and the provider references before authorizing a correction. Identify whether any fulfillment or customer message followed that mark. An internal status correction must remain connected to what actually happened; it should not erase an earlier shipment or imply funds moved when they did not.
Give the integration owner a precise mismatch
The useful handoff identifies the actual object type, status, order reference and store action that followed. Ask which recorded event caused the order to be marked paid and what separate evidence the integration requires for collection. This narrows the investigation to the setup-to-order mapping without asserting that a particular plugin or notification caused the error.
For a Prism checkout-review consultation, describe the visible setup result, the store’s payment label and whether a matching collection record has been found. Confirm any implementation or account-access work within the agreed scope before changes are made. Setup functionality does not establish that the provider has approved the research-only business, and this comparison does not authorize future charges.
Setup-versus-payment record
Use one real order and distinguish setup from collection in every row. Keep private records in authorized systems and enter only non-sensitive references. Mark unavailable evidence as unknown; do not turn a missing record into a zero-payment finding.
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.
Setup-versus-payment record. The last column is for temporary notes.
Fact to establish
Where to look
How to interpret it
Your finding
Completed object type
Where to lookThe provider object referenced by the store or integration.
How to interpret itA SetupIntent saves credentials; a PaymentIntent is the separate payment flow. A method reference alone is insufficient.
Object status
Where to lookThe status on that exact object, with the observation time.
How to interpret itSetupIntent succeeded confirms setup, not collection. Read status together with object type.
Order association
Where to lookThe order’s provider reference and the matching account record.
How to interpret itConfirm this payment belongs to this order; the customer’s identity alone does not establish the match.
Charge reference if any
Where to lookThe charge associated with a separate payment for the order.
How to interpret itSetup itself creates no charge. Check the associated payment result instead of treating a charge reference alone as collection proof.
Amount actually collected
Where to lookThe matching payment record’s collected amount and currency.
How to interpret itCompare with the order obligation. Do not substitute the intended amount or infer that the whole order is unpaid from setup alone.
Store action already taken
Where to lookThe order history, fulfillment record and sent confirmation, where they exist.
How to interpret itIdentify what followed the setup success and preserve that history before any authorized correction.
Order decision
Where to lookThe verified collection finding and the merchant’s fulfillment controls.
How to interpret itRecord payment verified, payment still in progress or collection unverified, with the owner of the next action.
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
The object and status meanings here are Stripe’s. Use another provider’s own documentation for a different integration.
A completed payment flow is not a promise of irreversible settlement, a bank payout or provider eligibility. Saving a payment method does not by itself authorize every future use.
Do not enter card numbers, security codes, authentication codes, client secrets, private payment links or customer records in this worksheet or the public inquiry form.
PaymentIntent and SetupIntent lifecycle — checked 2026-09-29. SetupIntents prepare payment credentials without creating a charge; succeeded confirms setup. PaymentIntents collect funds through a distinct lifecycle, including confirmation, action, processing, capture and success stages. Authentication can occur during setup without payment.