Invoice data is complex and changes per transaction
Plan name, amount, currency, tax, invoice number, billing period — each field must be rendered correctly from the transaction.
Invoice created, payment received, plan changed — each fires a billing event. else.events renders the right receipt or invoice email with all payment details from the payload.
Plan name, amount, currency, tax, invoice number, billing period — each field must be rendered correctly from the transaction.
Invoice created, payment successful, plan upgraded, refund issued — each needs a distinct email with appropriate copy.
A generic "view invoice" link is not useful. The link must be per-invoice, often with a signed URL.
EU customers may need VAT information. Formatting currency and dates correctly per locale is custom logic.
invoice.created, invoice.paid, subscription.plan_upgraded — each routes to the appropriate template.
Include amount, currency, plan, invoice_number and invoice_url. The template renders them without application-side rendering.
Include the user locale. Rules route to locale-specific templates that format dates and currency correctly.
Update the payment confirmation email copy in the else.events UI — no code change, no release.
{{ user.name }}Customer display name{{ data.plan }}Plan name at time of invoice{{ data.amount }}Invoice total with currency{{ data.invoice_number }}Human-readable invoice reference{{ data.invoice_url }}Personalised link to view or download the invoice{{ data.billing_period }}Billing period covered by the invoiceFire the billing event. else.events renders the right email with all payment details.