A receipt tells a customer that a financial event has happened. Sending it too early can misrepresent the state of an order. The browser returning to a success page is a useful user-interface event, but it should not be the sole authority for whether a payment succeeded.
Use your verified payment state
Your application should validate the payment provider's event through its documented integration and update the order accordingly. Send the receipt after the relevant state is committed. The Sendar email call is a consequence of that decision, not a payment verification mechanism.
Payment events may be retried or arrive more than once. Preserve the provider event identifier and your own receipt event identity. A duplicate notification should not create a second unrelated receipt send.
Make the message useful on its own
Include a recognisable business name, an order or invoice reference and the amounts and currency from the authoritative record. When a date matters, present it consistently with the order. Link to an authenticated account page for details that should not be embedded in email.
Do not include payment credentials or unnecessary sensitive information. If the customer needs a downloadable document, decide whether an authenticated link or an attachment better fits its size and access requirements.
Keep delivery failure separate from payment failure
If the email request fails, the successful payment should remain successful. Track the receipt as a separate operation that can be inspected or retried according to its result. Reversing an order because a message timed out would couple two unrelated failure paths.
Use Sendar's returned message ID to connect email history to the order. For a single-email transport retry, retain the same idempotency key and exact payload. If the result is uncertain, inspect before issuing another send.
Handle corrections as new events
A refund, corrected invoice or changed booking is not a retry of the original receipt. It needs its own application state, copy and event identity. Keeping those events distinct produces a clearer customer timeline and makes support easier when someone asks why a second message arrived.