Costs and account terms

A partial-capture reversal is labelled as a refund movement

Keep the generic transaction type and reporting category together, then match the movement to the originating payment’s authorization and capture records. Stripe can report a partial-capture reversal with type refund and reporting category partial_capture_reversal. That event differs from a later refund of captured funds. Classify the documented reversal separately so the released uncaptured amount is not reported as another customer refund merely because the generic label says refund.

For: A research-only merchant reconciling a refund-labelled entry associated with a payment captured for less than its authorized amount.

Updated 2026-10-01

Read the category before grouping the row

A report filtered only on type refund can include more than the later refunds you meant to count. Stripe’s reporting categories distinguish a partial-capture reversal from a customer refund after capture. Preserve the original row, including its reference, type, reporting category, amount, currency and time, before changing any summary classification.

When the category is partial_capture_reversal, follow that meaning into the payment history. When the category is absent from your export, the generic type cannot resolve this question alone. Obtain the corresponding provider detail or a report carrying the category. Do not rename every refund row based on the fact that the store sometimes captures partial amounts.

Establish what was authorized and what was captured

Authorization is the hold before capture. Stripe documents that capturing less than the authorized amount normally releases the remainder and that most payments permit one capture. Supported multicapture is an exception requiring its own evidence. The amount authorized is therefore not automatically the amount collected, and an unshipped portion of the order is not automatically a remaining capturable amount.

Find the payment that originated the report row. Read the authorized amount, captured amount and their currency from that payment’s records, with the relevant capture event. Compare the difference with the movement being investigated. The arithmetic is a consistency check; the provider category and the originating reference establish which event the row represents.

If the amounts disagree, keep the discrepancy open. Check whether you selected the correct payment, capture event and currency. A matching store total is not a substitute for that chain, and a convenient difference is not evidence that a row is a partial-capture reversal.

Separate a released remainder from a later refund

For the reconciliation, retain a distinct classification for the confirmed partial-capture reversal. Keep the captured portion tied to its capture record and any later customer refund tied to its own refund record. This prevents a summary from describing the uncaptured remainder as funds collected and then returned later.

A payment can require more than one classification across its history. Finding a partial-capture reversal does not establish that no later refund exists. Review the subsequent records before making that wider claim. If a later refund is present, preserve both events and their dates rather than replacing one with the other.

This is a technical reconciliation distinction. It does not choose a tax treatment or accounting policy for your business. Retain the provider’s original labels beside your explanatory classification so the person responsible for the books can trace the conclusion back to the source.

Correct the summary without inventing a payment action

If the source category and payment history agree, correct the summary that counted the reversal as a later customer refund and retain the supporting reference. Do not edit the original provider evidence or issue a refund to make the report match an earlier description. If the link or category remains missing, report the row as unresolved and identify the exact missing record.

Use the same distinction in a support handoff: record what was captured and what was released, then separately state any verified later refund. Neither a refund-labelled balance row nor the release of a hold establishes when a customer’s bank display changed.

A Prism research-only payment-processing consultation can address how to frame this report mismatch for the provider. Describe the store and the field that is confusing without uploading transaction or customer records to the public form. Scope, responsibilities, fees and terms are discussed before work; the provider controls its records and account terms. Follow-up is by email, and an inquiry does not book a time, buy a service or submit a processing application.

Partial-capture movement check

Use one actual report row and its originating payment. Keep the source fields unchanged. Confirm a separate partial-capture-reversal classification only when the category and payment history support it; otherwise name the missing evidence.

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.

Partial-capture movement check. The last column is for temporary notes.
Comparison pointSource evidenceInterpretation ruleYour finding
Generic transaction typeThe type value on the provider balance row.A refund type alone does not distinguish a partial-capture reversal from a later refund.
Reporting categoryThe reporting_category value on the same row or corresponding provider detail.partial_capture_reversal identifies the relevant technical category; record missing if unavailable.
Original payment referenceThe provider relationship from the movement to its originating payment.Use an explicit relationship, not an amount or store description that merely looks similar.
Authorized amount recordThe authorization amount and currency for that payment.This establishes the hold being compared, not an assumption about the amount ultimately collected.
Captured amount recordActual capture amounts and dates on the same payment.Identify the captured portion and check how it differs from the authorization.
Movement comparisonThe reversal amount and currency against the linked authorization and capture.Matching arithmetic supports consistency; conflicting amounts stay unresolved.
Later customer refundAny separate refund record after capture, with its own reference and state.Do not let one reversal row hide a distinct later refund or create a refund that has no record.
Summary correctionThe affected report grouping and the original evidence retained beside it.Separate the technical event while leaving accounting policy to the responsible owner.

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 labels refund and partial_capture_reversal here describe Stripe reporting. Use another provider’s definitions for its reports.
  • A normal partial capture releases the remainder; retaining it for further captures requires supported multicapture. No capability or deadline is inferred for an unseen account.
  • This classification does not authorize a refund, establish tax treatment or prove customer statement timing. Keep payment secrets and customer records out of the worksheet and public form.

Sources

  • Stripe reporting categories and types — checked 2026-09-29. A partial-capture reversal can have type refund and category partial_capture_reversal. It is distinct from a later customer refund; technical reporting categories do not establish universal accounting conclusions.
  • Stripe authorization and capture: partial capture boundary — checked 2026-09-29. Authorization and capture are distinct. Capturing less normally releases the remainder, and most payments allow only one capture unless supported multicapture applies.
  • Prism solutions — checked 2026-09-21. Prism provides storefront review, card-processing preparation and help with provider website questions. Scope, fees and terms are discussed before work; the provider decides account terms.
  • Prism contact — checked 2026-09-21. The form requests website, products and question without card details, passwords or customer records. Email follow-up does not make the inquiry an appointment, purchase or processing application.

Discuss my processing options

Want to talk through your own processing situation?