Receipts for recorded payments

Open Finance → Payment receipt delivery or the native Finance → Payment receipts tab. Prepare a client acknowledgment for a settled card or ACH payment, a reconciled manual payment, a settled refund or a manual correction. Nothing is sent merely because a record appears in the list.

A receipt starts with recorded evidence

A pending authorization or unsettled ACH payment cannot produce a payment receipt. Historical paid flags do not qualify. Card and ACH receipts require the original checkout to be settled; manual acknowledgments clearly say the business recorded the payment rather than claiming independent bank confirmation. Existing autopay receipts remain in their mandate workflow.

The preview includes the individual principal, gratuity, date, invoice and receipt identifier. It excludes private notes, bank references, provider identifiers and fee records. Later refunds or corrections to that original payment are shown separately. A correction acknowledgment explains that it reverses a recorded payment; it does not claim a new transfer occurred.

Review the exact recipient

The recipient comes from the current primary client, explicit booking-journey recipient or mini-session reservation. This desk does not accept arbitrary addresses. Review the exact text, then approve delivery. Normal invoices include the current invoice link; controlled booking and mini-session receipts refer to the recipient’s existing permitted link and do not reopen a cancelled booking or bypass document gates.

Finance-write and message-write authority are both required to queue or control delivery. Workers check the approving account and exact source again. A changed recipient, correction or source stops the old notice. Preparing a new, current receipt keeps the original email and financial history intact.

Delivery and recovery

The same original request and content have one retained delivery attempt. Duplicate approvals do not send duplicate mail. Cancel an unattempted receipt, or retry its exact original after a known pre-send configuration issue. An email already attempted cannot be recalled. An unknown provider outcome stays uncertain when its source changes or the safe retry window ends; inspect the original provider receipt instead of sending a replacement blindly.

Signed provider callbacks can reconcile an original attempt. Sent means provider acceptance; delivered is a separate signal. Neither is proof of readership, a new payment, a confirmed reservation or tax treatment. Download the exact retained text and content hash from the web history.

On native, financial records are read online. The app protects an explicitly approved request on the device before sending it, so a connection loss can recover the same request ID. It clears displayed financial details when backgrounded. It does not silently rebase financial approvals or enqueue automatic offline sends.

Configure the email sender, signed callbacks, operations worker and paymentReceiptDelivery feature gate during the combined activation phase. Approvals stay queued until sending is active. Real provider, browser and physical-device delivery rehearsals remain separate launch gates.