# Refund receipts reach the client again

## What was wrong

When you refunded a payment with **Email** ticked, the money always moved
correctly — that part was never affected. The receipt email, however, was only
ever sent to one saved field on the original payment, and that field is filled
in by a few checkout types (guest bookings, gift cards) and not by most others.
For a payment without it, the receipt could not be addressed, so nothing was
sent.

Two things then made it worse. The refund window told you a receipt would be
emailed to the client's contact address, which was never the address the receipt
actually used. And behind the scenes the refund kept trying to send the same
impossible receipt every few minutes, for as long as the refund existed, so the
refund never finished tidying itself up.

## What changed

**The receipt now has somewhere to go.** When a refund receipt is requested, the
destination is worked out once, from the strongest evidence available, in this
order:

1. the receipt address saved with the original payment;
2. the payer address saved with the original payment;
3. the client account's own email, but only when that account belongs to this
   venue and to this payment, and only when the address matches the one the
   client **confirmed** when they signed up. An address that was typed into an
   account but never confirmed does not count as verified, so it is not used.

A client who has left — archived by a bulk action or by support — still gets
their receipt at that address. The refund is about money this venue already took
from them, and leaving does not change that. A membership the venue has
**suspended**, or one that was only ever invited and never accepted, does not:
those resolve to "no receipt can be sent".

Nothing else is ever used. A staff member's address, the address of whoever took
the payment, and anything typed into the refund window are never a receipt
destination. Whatever is chosen is saved on the refund before anything is sent,
so editing a profile afterwards cannot redirect a receipt that has already been
issued.

**The refund window now tells you the truth before you confirm.** It names the
address the receipt will actually go to, and — when it differs — points out that
the client's contact address on file is a different address. If no receipt can be
sent at all, you get a clear warning before you press the button:

> No email receipt can be sent for this payment, because the original payment has
> no saved receipt address or payer address, and the client account has no
> verified email. You can still refund — the money moves as usual, and the
> "receipt not sent" outcome is recorded with a task for staff to follow up.

You can still go ahead. The refund is not blocked.

**A receipt that cannot be sent is now closed, not retried forever.** When there
is no destination, or when an earlier delivery attempt ended in a state that
cannot safely be repeated, the refund records "receipt not sent", raises the
usual follow-up task on the payment, and finishes. The same applies to receipts
whose delivery outcome is genuinely unknown: the system says so once rather than
attempting the same send again.

**Refunds show up on the client page.** A refund taken from the payment page,
the POS or the daily-sales drawer now refreshes the client's Billing tab as
well. And one refund is shown once: a refund that was split between a card and
account credit used to appear twice, with the card part labelled as the whole
refund. It now shows as a single refund at its full amount. A refund that failed
or was cancelled no longer reduces how much of the payment you can still refund.

## If a receipt was closed as "not sent"

Be aware of one limit, so nobody waits for something that will not happen: once a
receipt is recorded as "not sent", the system does **not** send it later by
itself, even if the client's email is corrected afterwards. That is deliberate —
it is what stops an edited profile quietly redirecting a financial document that
was already issued and closed — but it means the follow-up task on the payment is
the thing that has to be actioned by a person. Today that means the venue sends
the client the receipt PDF from the payment page. There is no self-service
"resend" button for these, and adding one is not part of this release.

## What you should do

Nothing, for new refunds. For refunds taken before this release whose receipt
never went out, the follow-up task on the payment lists them; those are being
reconciled separately — each one is either sent to a verified address or closed
as "receipt not sent". No refund is re-run and no money is touched by that work.

## Compatibility

| Combination | Result |
|---|---|
| The release serving production today + this release | Safe. This release adds no database change of any kind — it reuses the existing per-refund work-item table, so both releases read and write the same rows. |
| This release + the database as it is today | The intended state; there is nothing to apply. |
| Refunds already stuck before this release | Picked up automatically on the next scheduled run and closed with a real outcome, or reconciled explicitly by the operational runner where the automatic retries had already been abandoned. |
| POS, payment page, client Billing tab, daily-sales drawer | All four use the same refund window and so get the same warning and the same receipt behaviour. |
| Business, Consumer and Branded apps | The refund wire response is unchanged in shape; the per-channel readout carries one extra optional marker that older clients ignore. |