Count collected payments separately from failed attempts
Group the records by the store order and the actual PaymentIntent references, then inspect each flow's status and associated successful charge. Stripe can return a failed PaymentIntent to requires_payment_method before a later attempt succeeds, so several attempt entries can describe one completed payment flow. Count verified collected amounts from the payment records, not attempt rows or repeated appearances of the same charge. Keep pending, uncaptured and failed activity separate, and inspect later refunds and disputes on the Charge before describing what remains collected.
For: A research-only store owner or operations lead whose internal payment history shows several attempts against the same order.
Start with the real order reference and every provider payment reference the store associates with it. Match records through those references, not only through an equal amount or nearby timestamp. Keep the provider account context with the mapping so records from separate account exports do not get mixed. If an order has more than one PaymentIntent reference, inspect each one rather than assuming all entries are retries of the same flow.
Then retain the attempt history beneath its PaymentIntent. Stripe's lifecycle documentation explains that a failed payment attempt can return the intent to requires_payment_method so the payment can be retried. A later success does not turn each earlier failed attempt into another sale. Conversely, the presence of one success does not establish that every other payment reference for the order failed. The complete mapping determines which records still need review.
Use the specific status to separate completed and unfinished flows
Stripe describes the Dashboard label as a summary and the PaymentIntent status as the more specific record. Succeeded means the payment flow is complete. Processing remains pending for asynchronous methods; the lifecycle document says those methods can take days. Requires_action means additional action is needed, while requires_confirmation identifies a confirmation stage. None of those unfinished stages should be counted as an additional completed payment because it appears as another line in the history.
Requires_capture identifies uncaptured or partially captured activity in the status mapping. Read the actual collected amount on the associated payment record instead of substituting the order total or authorized amount. Keep any uncaptured remainder separate. A report that only exposes a summary label is insufficient for closing an ambiguous collected-payment count.
Count collections once and keep subsequent changes visible
For each associated charge, record the unique reference, the amount actually collected, its currency and the recorded time. If that charge appears in more than one export row, it remains one charge; check that the rows describe the same record before removing repeated appearances from the counting sheet. Sum collected amounts only within the stated currency and reporting window. Keep the number of attempts, number of completed flows and collected amount as separate measures.
Stripe's payment-status documentation places later refunds and disputes on the Charge. An intent that completed earlier does not by itself tell you whether funds were later refunded or disputed. Preserve the original collection and the later event as separate facts. If the report asks for current net receipts, state the later adjustments it includes; if it asks for original collections, do not silently replace that measure with a net figure.
More than one verified successful charge linked to one order calls for an order-to-payment reconciliation. It does not automatically establish an erroneous duplicate: first determine what each real charge represents in that order's records. Multiple failed attempts followed by one verified collection call for correcting the count, not a refund based on the number of rows.
Close the count or name the exact unresolved payment
Finish when every payment reference for the order is classified, each included collection points to a charge, and repeated export appearances have not been counted twice. An unresolved processing status, missing charge detail or uncertain order association stays on an exception list. Record when the status was read so a later outcome can be distinguished from an earlier counting mistake.
For a Prism checkout consultation, summarize the platform, the order-to-payment mismatch and which status remains uncertain. Scope, responsibilities, fees and terms must be agreed before any requested investigation or implementation. The public form is for the website, research-only products and question, with email follow-up; it is not a place for customer records or credentials and does not authorize a payment action or submit a processing application.
Attempt-versus-payment reconciliation
Complete a set for one real order, repeating the payment and charge entries for every associated reference. The outcome should distinguish attempts, completed flows and collected amounts. Keep an uncertain reference unresolved rather than turning it into either a sale or a zero.
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.
Attempt-versus-payment reconciliation. The last column is for temporary notes.
Record
Evidence to retain
How to count it
Your finding
Order reference
Evidence to retainThe internal order reference and its recorded provider associations, without customer details.
How to count itThe order groups the investigation; its existence is not a payment count.
PaymentIntent reference
Evidence to retainEvery linked intent identifier, its provider account context and the evidence connecting it to this order.
How to count itInspect each distinct flow; do not assume every attempt for the order shares one intent.
Attempt outcomes
Evidence to retainDated statuses in the actual intent history, including failed attempts and a later result where present.
How to count itFailed attempt rows do not add to collected payments.
Current flow status
Evidence to retainThe specific PaymentIntent status and when it was checked, alongside any Dashboard summary label.
How to count itSeparate succeeded from unfinished activity; investigate actual collection for uncaptured or partial states.
Successful charge reference
Evidence to retainThe associated charge identifier and evidence of successful collection.
How to count itCount the same charge once even when several rows refer to it.
Actual collected amount
Evidence to retainRecorded collected amount, currency and time from the payment evidence.
How to count itUse that amount, not the order total or requested authorization; keep currencies separate.
Later refund or dispute
Evidence to retainThe Charge's later event references and recorded amounts and statuses.
How to count itShow later adjustments separately and state whether the report measures original collections or net receipts.
Unresolved association or state
Evidence to retainThe specific missing link, amount or status and the authorized person who can inspect it.
How to count itLeave the exception open; do not refund or retry to make the report balance.
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
Stripe lifecycle names describe Stripe objects. Other providers need their own status definitions and collection evidence.
A completed payment flow does not establish an irreversible bank settlement, final net receipts or merchant eligibility.
This worksheet does not authorize refunds, cancellations, retries or fulfillment. Keep card numbers, authentication codes, payment-link tokens, API secrets and customer records out of it and the public form.
PaymentIntent and SetupIntent lifecycle — checked 2026-09-29. A failed PaymentIntent attempt can return to requires_payment_method before retry. Confirmation and additional-action states differ, asynchronous processing can take days, and succeeded completes the payment flow.
Payment status updates — checked 2026-09-21. Dashboard labels summarize specific PaymentIntent statuses, including succeeded, processing and requires_capture; later refunds and disputes are recorded on the Charge.
Prism solutions — checked 2026-09-21. Prism offers storefront review, processing preparation and help with provider website questions; scope, fees and terms are discussed before work, and the provider decides eligibility.
Prism contact — checked 2026-09-21. The form takes the website, products and question, excludes card details, passwords and customer records, and leads to email follow-up rather than an appointment, purchase or application.