A card refund waiting for available balance is still pending

Identify the refund before interpreting the balance

Open the provider refund linked to the original payment and compare it with the refund recorded against the store order. Check the refund amount and currency as well as the association. If an order has more than one partial refund, use the particular refund being queried; the status of a different refund on the same payment does not answer this case.

Record the payment method from the provider's payment record. The insufficient-balance behavior described here is specific to card refunds on Stripe. A WooCommerce payment-method label or a customer's description should not substitute for the provider record when the method is uncertain. If there is no matching provider refund, a store-only record does not establish a pending Stripe refund.

Available balance is the relevant condition

Stripe's refunds documentation says refunds draw from available balance, excluding pending amounts. For a card refund that the available balance cannot cover, Stripe holds the refund pending until the balance is sufficient. A pending balance or an expected incoming payment is therefore not evidence that the required available funds already exist.

Read the explanation attached to the refund or a provider response about that same reference. Record whether it explicitly identifies insufficient available balance. A low balance observed later can be consistent with that explanation without proving why the refund entered pending. If the reason is absent, the accurate conclusion is pending, reason unconfirmed; preserve the observation time and ask for the missing condition.

If the balance now appears sufficient but the refund still shows pending, record both observations with their times. Do not replace the status with succeeded or infer a release deadline. The account owner should use Stripe's actual instructions for that account and refund. This comparison does not establish that a transfer, a new sale or any other balance-changing action is authorized or will finish the refund.

Keep provider state separate from store administration

Stripe's Refund object distinguishes pending, requires_action, succeeded, failed and canceled. Copy the exact current word. A refund still pending is not a failed refund, and neither state means the customer has received funds. If the state changes, update the case from that new record rather than continuing to describe the earlier balance wait.

WooCommerce manual refunds and order-status changes do not themselves move money. A Refunded order or a refund email cannot replace the provider refund record. Equally, changing the store label will not supply available Stripe balance or complete a provider refund. Keep the store entry and the provider status visible as two facts when they differ.

Do not treat requires_action as an instruction to collect new bank details for a pending card refund. Stripe documents bank-detail collection for certain other methods without native refund support; that method-specific process is not a generic remedy for this condition. Do not create another refund or choose a different payment route while the existing card refund remains unresolved.

Make the next check a commitment your team controls

Review what support last told the buyer. If the message said money had already arrived while the provider still showed pending, correct the status claim using the verified record. Where Stripe explicitly attributes the wait to available balance, explain that recorded condition without presenting a bank-arrival date. Where the cause is unknown, say so rather than supplying the balance explanation from this article.

Assign an authorized owner to the existing refund and a date for checking that same reference again. The follow-up date is a team action, not a promise of bank receipt. Any provider-directed next action should be recorded with its source and the person permitted to perform it.

For recurring disagreements between refund messages and provider records, a Prism checkout consultation can start with the platform, exact status and a non-sensitive description of the mismatch. Agree the scope, responsibilities, fees and terms before work. An inquiry does not move funds or authorize a refund action.

Pending-refund status brief

Use one existing refund. Keep full provider references in your authorized internal case system; enter only an internal alias or match result here. The balance explanation is confirmed only when the actual case evidence states it. A follow-up date is not a bank-arrival promise.

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.