Void or refund a donation? Check the payment status first

To decide whether to void or refund a donation, start with the payment processor’s current state—not the donor’s request, the gift record, or the receipt. Cancel an authorization that has not settled, refund a settled payment through its original payment path, and keep a disputed payment in the dispute workflow until your processor says another action is safe.

That sequence prevents two expensive mistakes: reversing the wrong transaction and reimbursing the same payment twice. It also gives a lean team one closeout rule: the payment, gift, receipt, and donor message must all describe the same outcome.

Freeze parallel actions and find the exact transaction

When a donor reports a duplicate gift or an incorrect amount, assign one owner and pause every other reversal attempt. Do not let one person refund in the fundraising system while another responds to a dispute in the processor.

Build a small correction record before clicking anything:

• original transaction or payment ID;
• gift ID and donor record;
• amount, currency, and payment method;
• current processor state;
• active refund or dispute, if any;
• requested correction and who authorized it.

Match on the processor’s stable ID, not only the donor name and amount. Two legitimate gifts can look identical, especially during a campaign. If the exact payment is uncertain, hold the request and investigate instead of choosing the most likely record.

This first check is also the boundary between a payment correction and a chargeback response. If the processor already shows a dispute, follow the donation chargeback workflow and keep the correction owner attached to that case.

Choose one reversal lane from the payment state

Processors use different labels, but the operating choice has three lanes.

Cancel or void an unsettled authorization

Use the processor’s cancel or void action only when the transaction is still in a state that supports it. For example, Stripe documents specific PaymentIntent states that can be canceled. Its refund guidance says an uncaptured `requires_capture` payment cannot be refunded as a completed charge; the PaymentIntent must be canceled instead.

Do not generalize those status names to another processor. Read the current transaction and use the action that its own interface permits. Record the final canceled or voided state rather than assuming the click succeeded.

Refund a settled payment

When the processor shows a completed payment, use its refund action against that original transaction. Stripe sends refunds back to the original payment method and notes that refunds can fail after initiation. Treat “refund requested,” “refund pending,” and “refund completed” as different states.

Keep the gift open in the correction queue until the processor confirms the outcome. A confirmation screen proves that staff submitted an action; it does not always prove the donor received the credit.

Keep an open dispute in the dispute lane

Do not issue a second refund merely because a donor also opened a bank or card dispute. Stripe warns of double-credit risk for some bank-debit payments when a merchant refund and bank dispute move at the same time. Its current guidance also directs merchants to handle a dispute instead of refunding when a charge is disputed while the refund is pending.

The safe action depends on the payment method and processor. Freeze the separate refund, preserve the case ID, and follow current processor instructions. A recent nonprofit operator discussion shows why this boundary matters: staff were actively deciding between a refund and an existing chargeback, with peers warning against two reimbursements. That discussion is demand evidence, not payment or legal guidance.

Append the reversal; do not erase the gift

Keep the original gift and payment record intact. Add a linked reversal record with the action, amount, reason, operator, timestamp, processor ID, and current state. For a partial correction, preserve both the original amount and the amount returned.

This is CharityStack’s recommended four-record closeout:

1. Payment: the processor reports canceled, voided, refunded, failed, or disputed with its stable ID.
2. Gift: the fundraising record keeps the original transaction and links the correction.
3. Receipt: the acknowledgment is voided, corrected, or held according to your policy and jurisdiction.
4. Donor message: the donor receives the exact amount and current status without a premature promise.

Current Microsoft nonprofit fundraising documentation illustrates why these records need separate checks: it treats refund processing, refund verification, and receipt voiding as distinct actions, and it does not automatically void a receipt when a gift is refunded. Other systems differ, so inspect the actual behavior of yours.

Correct the receipt after the money state is clear

A receipt is not a substitute for the payment record, but it cannot be ignored. Current IRS guidance explains U.S. written-record and acknowledgment requirements for charitable contributions. Your organization’s jurisdiction, gift policy, and advisers control whether a donation may be returned and how an acknowledgment should be corrected.

Operationally, wait for a confirmed money state, then follow that policy. If the refund fails, do not issue a message that says the gift was returned. If a receipt was already sent, preserve its identifier and record the correction instead of silently replacing history.

CharityStack’s fundraising operations workspace keeps payments, contacts, receipts, and payouts connected. Whatever system you use, close the task only when those records agree with the processor.