Account emails

The receipt email: what a small app's payment receipt has to carry

A receipt is the one email people keep on purpose. They forward it to a bookkeeper, search for it at tax time, and open it when a charge on their card statement looks unfamiliar. What a small app's or a freelancer's payment receipt has to carry, what the tax rules add, and the two mistakes that send the same receipt twice or not at all.

Most receipt emails are read twice: once in the minute after paying, to see that it worked, and once months later, by someone looking for a specific thing. "What was this £12 on my card?" "Which address did I put on the invoice?" "Can I claim the VAT back?" The first reading forgives almost anything. The second one is where a receipt earns its keep or sends someone to your support inbox.

Seven parts. Each one answers a question someone will have months later.

Receipt or invoice?

An invoice asks for money; a receipt says the money arrived. Many small apps take payment first, so the email they send is a receipt, but in countries with VAT or GST a business customer may also need it to work as a tax invoice, the document that lets them claim the tax back. If you're registered for VAT or GST, write the receipt so it qualifies. It costs a few extra lines and saves a back-and-forth with every business customer.

What every receipt carries

Part	The question it answers later
From name that matches the card statement	"Who is this?" If the statement says `TALLY*INVOICES` and the email says "Sam from Tally Labs", people search for the wrong word. Use the same name in both places.
A subject with the word "receipt" and the amount: "Your Tally receipt: £12.00"	It's what people type into their mail search. "Thanks for your order!" is found by nobody.
A receipt number and the date paid	Support finds the payment in seconds. Sequential numbers are also what tax rules ask for (below).
What was bought: name, quantity, price, and the period for a subscription	"Pro plan, 15 Oct to 14 Nov 2026" ends the "did I pay twice?" email before it's written.
The total, with tax shown separately if you charge it	The number on the card statement, so it should match it exactly, currency included.
How it was paid: card brand and last four digits	"Which card did I use?" Never more than that; see below.
Your legal name, address and a way to ask a question	A bookkeeper needs the first two, the customer needs the third. Stripe's own receipts always carry the legal business name, a support address and a support email.

What the tax rules add

The rules differ by country; these are the two most small sellers run into first. Check your own country's tax office if you sell elsewhere.

UK, VAT-registered. For a sale of £250 or less including VAT, HMRC accepts a simplified invoice: your name, address and VAT number, the time of supply, a description of what was supplied, and for each VAT rate the total including VAT and the rate. Over £250 it has to be a full or modified VAT invoice, which adds a sequential number and the customer's name and address, among other things (VAT Notice 700/21, section 4).
EU. The VAT Directive lets member states allow simplified invoices up to €100: the date, who supplied it, what was supplied, and the VAT or what's needed to work it out (Articles 220a and 226b). A business buyer in another member state needs a full invoice with both VAT numbers.
US. No national rule says what a receipt must show. Whether sales tax is shown as its own line depends on the state you collect it for.

If you sell to businesses, add an optional "company name and tax number" field at checkout and print it on the receipt when it's filled in. That's most of the gap between a receipt and a tax invoice.

What never goes in

More of the card number than the last four digits, and never the expiry date or the security code. The card industry's own rules (PCI DSS) treat the full number as something to hide whenever it's displayed; an email is displayed in a lot of places for a very long time.
A link that signs the person in. Receipts get forwarded to accountants. A "View your account" button should open the sign-in page, not the account.
Offers. A receipt confirms a transaction the person already agreed to, which is what makes it a transactional email under CAN-SPAM in the US. An upsell block pushes it towards advertising, to the law and to the mail providers that sort it. Sell in a separate email, to people who said yes to that. Transactional or marketing has the full line.

Exactly once: the two bugs

The receipt that goes twice. Payment providers retry webhooks. Stripe's docs say an endpoint may receive the same event more than once and should ignore events it has already handled, and that sometimes two separate events are sent for the same payment, so the event id alone doesn't catch every repeat. If your handler sends the receipt every time the "payment succeeded" event arrives, some customers get two, and two receipts look like two charges. Record that the receipt was sent, on the payment's own row, and check it before sending:

-- one row per payment, keyed by the provider's payment id
UPDATE payments SET receipt_sent_at = now()
 WHERE provider_payment_id = $1 AND receipt_sent_at IS NULL
RETURNING id;
-- no row back: someone already sent it, so don't send again

The receipt that never goes. If the email is sent from the browser's "thank you" page, it's lost whenever the person closes the tab before the page loads, and slower payment methods (bank debits, transfers) only succeed days later. Send it from the server, on the event that says the money arrived.

The same two rules hold for refunds: a refund gets its own receipt, with the original receipt number on it, sent once.

An example

From: Tally
Subject: Your Tally receipt: £12.00

Receipt 2026-00142 · Paid 15 Oct 2026

Pro plan, 15 Oct to 14 Nov 2026     £10.00
VAT 20%                              £2.00
Total paid                          £12.00

Paid with Visa ending 4242.

Tally Labs Ltd, 1 Example Street, London
VAT GB 123 4567 89

Questions about this payment? Reply to this email.

Plain text works. If you send HTML as well, keep the text version: it's what some mail apps show in previews and what gets pasted into a bookkeeping tool. See every HTML email needs a plain-text twin.

Sending it with email59

One call to /v1/send from your payment webhook, after the UPDATE above returned a row. Set reply_to to an inbox you read, so "Reply to this email" reaches you (Replies). If you take payments through a provider that can send its own receipts, pick one sender, not both.

curl -s https://email59.com/v1/send \
  -H "Authorization: Bearer $EMAIL59_KEY" -H 'Content-Type: application/json' \
  -d '{"from":"yourapp","to":"sam@gmail.com","reply_to":"billing@yourapp.example",
       "subject":"Your Tally receipt: £12.00",
       "text":"Receipt 2026-00142 · Paid 15 Oct 2026\n\nPro plan, 15 Oct to 14 Nov 2026  £10.00\nVAT 20%  £2.00\nTotal paid  £12.00\n\nPaid with Visa ending 4242.\n\nTally Labs Ltd, 1 Example Street, London\nVAT GB 123 4567 89\n\nQuestions about this payment? Reply to this email."}'

The other payment email, the one when a card fails, is a different job: the missed-payment email that gets the card updated.

The short version

From name the same as the card statement; "receipt" and the amount in the subject.
Receipt number, date paid, what was bought (and the period), total with tax, card brand and last four.
Your legal name, address, tax number if you have one, and a reply address that reaches a person.
VAT or GST registered: write it so it qualifies as a simplified tax invoice, and offer a company field for business buyers.
No full card number, no sign-in links, no offers.
Sent once, from the server, when the money has actually arrived. Refunds get their own.

Sources

Send your first email More articles

Visa is a trademark of its owner; Stripe, Postmark and SendGrid are named for their public documentation. email59 is not affiliated with any of them.