Does a paid booking need a receipt, an appointment confirmation, or both?

A payment receipt answers whether a payment succeeded. An appointment confirmation answers whether a booking is confirmed. For a business that takes payment when booking, both may be useful—but only when each reflects a real, verified event. Do not treat a successful charge as proof that a slot is reserved, or a reserved slot as proof of payment. This checklist helps you decide which message belongs at each stage before implementing the email integration.

Start with what your business actually promises

Write down the condition that makes an appointment confirmed in your booking system. It might be a reserved slot, a reservation after successful payment, or a booking accepted by a staff member. The right email trigger follows that condition—not simply a customer clicking the booking button.

For example, a salon might reserve an appointment only after a deposit succeeds and the booking record is saved. A consultant might collect payment before manually agreeing on a time. In the consultant's workflow, the payment can justify a receipt while the appointment remains unconfirmed. Sending an appointment confirmation at checkout would promise more than the booking system knows.

Identify the authoritative payment record and booking record, then document which state in each permits a message. This gives your team a clear basis for telling customers what they have paid and whether they have a confirmed appointment. If your team cannot distinguish those states, resolve that workflow ambiguity before adding email.

Use a decision checklist for incomplete and completed bookings

Payment verified and appointment confirmed: consider a receipt for the payment and an appointment confirmation for the reserved booking. A receipt gives the customer a payment reference; a confirmation communicates the confirmed booking. Each message needs its own valid authorization.

Payment verified but appointment pending: send a receipt only if the payment meets Emailer API's documented Stripe-verification requirements. Do not issue an appointment confirmation until your application can verify the confirmed booking. Make the pending state clear in your own booking interface, especially if staff approval or availability checks remain outstanding.

Appointment confirmed but payment not completed: send an appointment confirmation only if your business genuinely permits that unpaid reservation. Do not send a payment receipt. If payment is a condition of confirmation, an unpaid provisional hold is not a confirmed appointment.

Neither state verified: neither message is justified yet. A checkout return page, an abandoned payment attempt or an unsaved slot selection should not stand in for the underlying records.

Connect each message to the correct Emailer API verification path

Emailer API requires Stripe verification for payment receipts. A booking database field marked paid does not replace payment-provider verification. Follow the current implementation reference at https://emailerapi.com/docs for the required Stripe setup and event checks. The supplied public documentation does not establish a supported receipt-verification path for another payment provider.

Appointment confirmations use a signed application callback. Your application must check the genuine booking event, recipient and message context rather than approve every request. The callback authenticates your application's assertion; it does not independently verify payment or manage your booking calendar.

Treat a paid appointment as potentially involving separate financial and booking events, not as permission to reuse one authorization for two messages. Emailer API binds each event authorization to one recipient and the exact sender and rendered content, and it can authorize only one queued message. Implement each verification path for the event it supports.

Keep deposit receipts and booking details accurate

If a customer pays a deposit, describe it as a deposit wherever the approved template permits payment details. Any linked receipt page should describe the actual payment rather than imply that the entire service is paid for. For example, a deposit toward a consultation does not establish that the remaining balance is settled. Keep your payment and booking pages consistent with that distinction.

Use the approved catalog template for each supported event and inspect its actual variable rules before deciding what can appear in the email. Emailer API uses fixed templates with constrained variables; arbitrary message content and attachments are outside the current sending contract. Do not assume you can combine a receipt and an appointment confirmation into a custom email.

Where the chosen template permits a link, use an allowed HTTPS destination on the verified domain. Review the destination as well as the email: a receipt page should not contradict the payment, and a booking page should not label a pending appointment confirmed.

Reminders can be useful when customers need to prepare for or attend an appointment, but they do not guarantee attendance. Do not assume Emailer API supports reminders, cancellation notices or promotional follow-ups merely because appointment confirmations are listed. Plan only around documented email types.

Prepare an exception checklist before launch

Record what staff should do when payment succeeds but booking confirmation fails. For example, flag the unmatched payment in your own operational workflow so someone can resolve availability and communicate through an existing authorized support process. Do not fabricate a booking event just to make an email send.

Before each send, validate the exact message you intend to send and resolve the reported blockers. Validation does not reserve capacity or guarantee delivery. If an event has become stale, consult the current documentation and investigate the underlying transaction rather than changing its timestamp to make it appear fresh.

Keep booking state separate from email outcome. A queued confirmation does not prove delivery, and an email failure does not by itself undo a genuine reservation. Use delivery logs and signed webhook events to inspect later outcomes; even a successful destination-server handoff does not prove inbox placement.

Finish with a written acceptance checklist: the business confirmation rule is explicit, each recipient matches the record required by its verification path, deposit and balance wording agree with the underlying transaction, each message has its own valid authorization, and staff have an exception-handling procedure. Then implement and test the actual integration. These planning examples are not tested code or evidence of a completed sending workflow.

Start with one verified customer event

Choose the first message your workflow needs: a receipt for a verified payment or a confirmation for a genuinely confirmed appointment. Connect that event and its approved template before adding the second path. The setup checklist at https://emailerapi.com/guides/transactional-email-setup walks through domain verification, templates, event connections and validation.

Get started free at https://emailerapi.com and choose your first supported email type. The plan costs $0 per month. New accounts start at 100 recipient reservations per day and 3,000 per calendar month, subject to shared capacity and sending safeguards. Check https://emailerapi.com/pricing before routing your booking workload.

Sources and next steps

Start free with setup help included · Read current plan limits

Reviewed by the Emailer API editorial assistant against the linked documentation. This guide explains the documented workflow; it is not a report of a new integration test.