Match the refund to the correct payment on the order

Build one payment map from the order outward

Use the order as the starting point, not as the proof of funding. Locate the gateway named on the order and follow the payment references in the merchant’s authorized systems. Record the provider and account context, the type of each reference, the linked payment, the currency and the amount the provider shows as captured. Keep the references in the internal case record; do not export customer details into a public inquiry.

Connect references that describe the same underlying payment instead of counting each identifier as another amount. The map may resolve to one captured payment, several documented captured payments, or an unresolved association. A failed attempt, an order reference or a notification reference is not enough to add a second captured amount. Leave the allocation open when the record does not establish which funds paid for this order.

If records do establish several relevant payments, retain each payment as its own line. That is a finding about this order’s history. It is not evidence that the checkout generally supports split tender, multiple captures or automatic refund allocation.

Attach prior refunds to their own original payments

Open existing refund records before selecting another action. For each one, identify its original payment, currency, amount, current provider state and corresponding store entry, if any. An amount recorded in two systems is not automatically two refunds; link the records before totaling them.

WooCommerce distinguishes recording a manual refund from returning funds through a supported gateway. Changing the order status alone does not move money. An automatic refund depends on gateway support, and a partial refund need not put the order into the full Refunded status. Neither the order’s overall status nor a manual refund entry gives you a complete provider allocation.

For Stripe, multiple partial refunds cannot total more than the original charge. Check that limit separately for each original payment rather than against a combined order total. Keep pending or otherwise unresolved refund records visible. Do not treat them as unused capacity and issue a replacement merely because the buyer has not yet seen the money. Use the current provider state to resolve the outstanding request first.

Allocate the decision before selecting the action

The merchant’s approved remedy supplies the amount to return; the payment map supplies the eligible original payment records. Write the proposed amount beside each identified payment and check that the allocated amounts, in the same currency, account for the authorized remedy. This is a reconciliation check, not a rule to divide every refund evenly or to refund the most recent payment first.

Where an allocation would exceed one payment’s remaining provider-confirmed capacity, do not move the excess to another reference simply to make the arithmetic fit. Establish whether that other record really funded the order and whether the authorized remedy covers it. If the order-to-payment relationship or the treatment of an existing refund remains unclear, hold that portion of the decision for reconciliation.

Stripe sends a refund back to the original payment method; it is not a way to select a different card or bank destination. Another provider’s actual rules govern its payments. Stripe also distinguishes a card refund waiting for available balance from other method types that can fail when funds are insufficient. A clear allocation identifies the correct target, but does not guarantee the provider can complete the refund immediately.

Keep the allocation through the handoff

The person authorized to act should receive the approved amount, its payment allocation and the existing-refund map together. After an authorized action, attach the resulting provider refund reference and current state to the same allocation. Support can then distinguish an amount approved for return, a store record, a provider request and a completed provider outcome without initiating a second refund to settle a wording mismatch.

When the store makes it difficult to trace those links, a Prism checkout-review consultation can start with the platform, gateway and a non-sensitive description of the missing association. Describe the research-only products and the question without sending order exports, customer records or payment details. Confirm the requested investigation and any implementation in the agreed scope, fees and terms. Email follow-up to an inquiry does not authorize a refund or submit a processing application.

Payment-to-refund allocation

Use one set for a real order. In the actual payment and refund rows, keep a separate internal entry for each identified payment. Do not fill gaps with assumed split payments. Allocation is unresolved until the payment links, earlier refund states and authorized amount agree.

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.