Saved payment methods are being counted as completed payment history

Success has to belong to a named record type

A mixed export can place setup and payment activity under similar success labels. Start by identifying the object or event type behind each row. Stripe's save-and-reuse guidance explicitly separates Checkout setup mode from charging: the setup flow saves a method without taking an initial payment. Its completion therefore cannot be counted as a completed charge simply because it was successful.

Keep the export unchanged and add a separate classification in your working copy. Distinguish setup-only records, actual payment records and rows whose type you cannot establish. If the export omits the type, find it in the authorized source record rather than inferring it from a customer name or a generic completed label. An unresolved row remains outside the substantiated collected-payment total until the underlying record answers the question.

A saved method is a link to possible activity, not an amount

For a setup-only row, record that no payment reference or collected amount is established by that setup. Do not copy a catalog price, order estimate or intended future charge into the history to fill the gap. Those figures can describe a commercial plan without showing a payment took place.

If the same customer later paid, use the actual later payment record and its amount. A shared customer or saved-method association is a reason to look for that payment, not a reason to assume it happened. Retain the setup reference as supporting context while counting the distinct payment under the provider's requested measure. Do not count both records as two payments.

Saving a method also does not authorize every possible future use. Stripe's guidance ties reuse to the use the customer agreed to. That consent record is relevant to future charging, but even valid consent is not historical payment evidence. This worksheet examines existing activity; it is not an instruction to charge saved methods to create history.

An actual payment still needs a status and amount check

Stripe's PaymentIntent status describes the payment flow more specifically than the Dashboard's summary label. A succeeded PaymentIntent marks a completed payment flow. Processing can mean an asynchronous payment is still pending. Requires_capture identifies an uncaptured or partially captured state. Do not include the entire intended amount as collected merely because a payment object exists or an authorization succeeded.

Where a payment has only been partly captured, use the amount actually captured if that is what the reporting request measures, and keep the uncaptured portion separate. For rows still processing or awaiting action, record the unresolved state and the time checked. Do not turn them into collected payments to match the store's order count.

A succeeded PaymentIntent also does not settle the separate question of later refunds or disputes. Stripe records those on the Charge. If the request asks for net activity, refunded volume or disputes, compare the relevant subsequent records. If it asks for gross completed payments, keep the original amount and later adjustments distinguishable rather than silently changing the measure.

Rebuild the requested history with a visible exclusion trail

Confirm the requested entity, account, period and reporting measure before totaling the classified rows. Count each payment once using its actual payment reference, not the number of export events associated with it. Use the date basis requested for payment activity; a setup date does not place a later payment into an earlier period. Keep different currencies separate unless the request specifies an agreed conversion basis.

Retain a short reconciliation showing which records contributed collected amounts, which were setup-only, and which remain unresolved. The original mixed-export row count can then be explained without presenting it as transaction count. When every available record is setup-only, the accurate statement is that this evidence establishes saved methods and no collected payments; it does not establish that the business has never received money through any other channel.

For a Prism processing consultation, describe the export types and the history measure requested, using aggregate findings. Prism's processing consultation concerns accurate preparation; the provider decides what evidence it accepts. Confirm scope, responsibilities, fees and terms before work, and keep raw exports and customer records out of the public inquiry.

Setup-versus-payment evidence map

Use this to define how you will classify your real export, then retain detailed references in your controlled working file. An unverified type, amount or state stays unresolved. The final column should contain record availability or a classification finding, not saved payment credentials or customer data.

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.