Two refund requests need a reference check before another attempt

Map each request to the original payment

Collect the two request records with their times, channels and responsible staff. Identify whether each was a buyer’s request, an internal instruction, a store action or an action in the provider account. A support ticket number identifies a conversation. It is not the provider’s refund identifier, and two tickets do not establish that two refunds were created.

Open the original provider payment using the association already recorded on the order. Check the account, amount and currency before comparing refunds. If the order has more than one payment, trace which payment each attempted refund targeted. Keep an action on a different payment outside this comparison until that mismatch is resolved.

For each request, locate any corresponding provider refund record. Use the record’s reference and timestamp to connect it to the request history. A matching amount alone is insufficient: repeated actions can request the same amount. If the connection cannot be established, label it unresolved instead of creating another refund to see what happens.

Count refund records and read each state

When both requests point to the same refund identifier on the same original payment in the same provider account, the records you found identify one refund. Keep both request histories, but do not count that same refund twice. Check its current state before deciding what support should say.

When there are two distinct refund identifiers, inspect both independently. They establish separate refund records, not necessarily two completed returns of funds. Stripe’s Refund object defines pending, requires_action, succeeded, failed and canceled. Record each exact status with the time it was checked; a request or a past status is not the current outcome.

When only one request has a located refund, or neither does, the missing association is a reason to investigate the action history. A failed screen response, a support promise or an absent store note does not by itself establish that the provider created nothing. Resolve the uncertain request before authorizing another attempt.

The amount ceiling does not decide whether an action was repeated

Stripe permits partial refunds whose total cannot exceed the original charge. That ceiling limits the total; it does not establish that two requests express different intended refunds. Repeated partial actions may concern the same customer request while still fitting below the original charge amount. Do not treat available refundable value as authorization to issue another refund.

Compare every distinct refund’s amount and currency with the merchant’s documented refund decision. Track succeeded amounts separately from pending or action-required records. Also retain failed and canceled records so that a later reader can explain the full history. Do not assume that a pending amount is free to request again, or derive a new authorized refund amount by subtracting only succeeded refunds from the charge.

For Stripe, insufficient available balance leaves card refunds pending, while other method types can fail in that situation. That documented possibility is not a diagnosis of this refund’s status. Some methods without native refund support use requires_action for Stripe’s specific bank-detail collection flow; read the actual next_action instructions when present. It is not a general instruction to ask a card customer for bank details or move the refund to another rail.

Give one authorized owner the next action

Name one owner to reconcile the requests before any additional refund action. If both requests identify one refund, update the support records to reference it and report its actual state. If distinct refunds exceed the intended refund decision, preserve both records and have that owner ask the provider about the actions available for their current types and states.

Do not promise that an unintended refund can be canceled. Stripe documents limits by type and state: some card refunds have only a short Dashboard cancellation window, and charge reversals cannot be canceled through that path. A failed or canceled refund also does not automatically authorize a replacement; first reconcile the other request and any remaining refund records.

If the review establishes a legitimate further amount to return, document the amount, original payment, prior refund history and approving owner before using the authorized provider workflow. This worksheet does not issue that approval. Support should distinguish a request received, a provider refund recorded and a provider-reported success, without promising when the buyer’s bank will show funds.

For repeated confusion between store actions and provider records, describe the channels, platform and unresolved reference mapping in a Prism checkout-review consultation. Leave actual refund identifiers, customer records and account credentials in authorized systems. Scope, responsibilities, fees and terms are confirmed before work; a consultation itself does not move money or decide processing eligibility.

Repeated-refund request comparison

Complete this against one original payment and the two real requests before another attempt. Record restricted locations for full references rather than copying private payment data. Resolve each request to a distinct refund record, the same existing record, or an explicitly unresolved outcome. Count each provider refund only once and preserve its status.

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.