Account for earlier partial refunds before the next request
List every distinct refund tied to the original provider payment, with its amount, currency and current provider status. Sum the succeeded refunds once per refund reference to identify the amount the provider reports as successfully refunded, and track pending, requires_action, failed and canceled records separately. Compare the full register with the original charge and the provider's current refundable amount before another action. Stripe limits the total of partial refunds to the original charge; that ceiling does not turn every unresolved request into either completed money or available capacity.
For: A research-only merchant handling another refund request on a payment that already has partial refunds or unresolved refund attempts.
Open the actual provider payment that funded the order and record its original charged amount and currency. If the order has more than one payment reference, make a separate register for each payment before combining any order-level summary. An order total is not a substitute for the amount on the payment being refunded.
Collect each refund reference attached to that payment. Link support requests, store entries and provider records to the same refund where the references establish that relationship. Several messages about one refund do not create several refunds, while several distinct refund objects must not be collapsed because their amounts match.
Preserve the date and status observed for each object. A request recorded by support with no located provider refund remains an unmatched request. Keep it visible while the owner investigates; do not count it as succeeded or create a replacement merely because the reference is missing from one screen.
Keep succeeded amounts separate from unresolved requests
Stripe's Refund object uses pending, requires_action, succeeded, failed and canceled. The current provider record determines which group each refund belongs in. Add the amounts of distinct succeeded refunds for a provider-reported successful-refund subtotal. That subtotal describes the provider result; it does not establish the buyer's statement appearance or guarantee an arrival time.
Track pending and requires_action amounts as open requests. They are not succeeded, but their existence must be considered before anyone requests more money back. Stripe documents that insufficient available balance can leave card refunds pending, while other method types can fail in that situation. For some methods without native refund support, requires_action can involve Stripe collecting bank details through its own instructions. These are method-specific conditions, not explanations to assign from a status alone.
Keep failed and canceled references in their own group with any recorded reason. Do not count them as successful refunds, and do not treat their labels as automatic instructions to submit again. A failed request may have related follow-up activity that still needs matching to the original payment. Record what the provider actually shows rather than inventing a reason or a new route.
Distinguish an arithmetic remainder from an actionable amount
Subtracting the succeeded-refund subtotal from the original charged amount gives the amount not yet reported as successfully refunded in this register. Label that figure accordingly. It is not automatically the amount you should request next, because pending requests, action-required requests and unmatched records remain unresolved.
Compare your categories with the original payment's current refund information and the amount the provider permits for another request. Stripe says partial refunds cannot total more than the original charge. Do not infer from that ceiling how every pending or failed state affects the amount available in your particular case; verify it in the provider record. If the provider figure and your register differ, reconcile the references and states before proceeding.
Check the records again immediately before an authorized new action if another person may have processed a refund since the register was prepared. Assign one owner to coordinate the next request. Record the resulting refund reference and state, then update the same register so the next colleague does not start from an earlier subtotal. Do not cancel an open refund just to make the arithmetic simpler; cancellation availability depends on the refund's type and state.
Give support a precise summary of what remains open
The useful handoff states the original payment, the succeeded subtotal, the separate open-request subtotal and any failed, canceled or unmatched records. It also identifies the amount still awaiting provider confirmation and who may authorize the next action. This gives support an answer about earlier partial refunds without presenting every request as money already returned.
Tell the buyer only the confirmed stage of the relevant refund. Do not promise an arrival date, imply that a failed status explains an undocumented cause or send an unapproved alternate payment to bypass an open request. Any method-specific action must follow the actual provider instructions; bank details do not belong in a Prism inquiry.
If multiple partial refunds repeatedly become difficult to reconcile across the store and provider, describe that workflow in a Prism checkout-review consultation. Bring a non-sensitive account of the mismatched records and ask to scope the help needed. Scope, responsibilities, fees and terms are confirmed before work; an inquiry itself does not authorize a refund or establish that funds moved.
Cumulative refund register
Complete this for one original payment. In your authorized internal record, repeat the prior-refund fields for every distinct refund reference and retain one current status per refund. Sum succeeded amounts separately from open requests. Treat any remaining figure as unverified for a new request until it agrees with current provider information. Use references only; do not enter payment credentials or customer bank details.
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.
Cumulative refund register. The last column is for temporary notes.
Register field
Evidence and calculation
Interpretation
Your record
Original payment reference
Evidence and calculationThe provider account context and payment reference actually linked to the refunded order.
InterpretationSeparate registers are needed when an order has several original payments.
Original amount
Evidence and calculationThe charged amount and currency on that provider payment.
InterpretationThis is the charge against which Stripe's total-refund ceiling applies, not a later edited order total.
Prior refund references
Evidence and calculationEvery distinct provider refund, its amount and currency, linked to any corresponding store entry or support request.
InterpretationCount each refund once; repeated messages and matching amounts do not establish additional refunds.
Current statuses
Evidence and calculationThe exact status and observation time for each refund, plus a reason only if actually recorded.
Evidence and calculationSum the amounts of distinct refunds currently reported as succeeded for this payment.
InterpretationShows provider-reported successful refunds, not a promised bank-statement date.
Open and unmatched requests
Evidence and calculationList pending and requires_action amounts separately, and identify requests lacking a verified provider reference.
InterpretationDo not count these as succeeded or ignore them when considering another request.
Remaining amount to verify
Evidence and calculationCompare original charge minus succeeded refunds with the provider's current refund information, taking open records into account.
InterpretationAn arithmetic remainder alone is not authorization or confirmed capacity for the next refund.
Next authorized action
Evidence and calculationThe decision owner, latest check time and any new refund reference and state after action.
InterpretationUpdate this register before another colleague handles a further request.
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's refund statuses and original-charge limit apply to Stripe; another provider's state meanings and permitted amount need its own documentation.
The register does not decide refund entitlement, prescribe an alternative payment rail or guarantee arrival. Refund cancellation depends on the actual method and state.
Do not include card numbers, authentication codes, private payment links, API secrets, bank details or identity documents in the worksheet or public inquiry.
Stripe refunds — checked 2026-09-29. Partial refunds cannot total more than the original charge. Available balance, payment method and actual refund state affect processing; insufficient funds can leave card refunds pending. Cancellation and requires_action behavior are method- and state-specific, not general retry instructions.
Stripe Refund object — checked 2026-09-21. Refund statuses include pending, requires_action, succeeded, failed and canceled. The status set alone does not establish an undocumented cause or the amount a merchant may request next.
Get help with store operations
Need help with the order, email or fulfillment step itself?