A receipt email confirms that a payment succeeded and gives the customer a record of it: the amount charged, the date, a transaction ID, what was purchased, and the payment method used, masked to the last four digits. It differs from an invoice email, which requests a payment that hasn’t happened yet; a receipt confirms one that already has. This guide covers the fields a receipt needs, how fast it should arrive, how much promotional content it can safely carry, and a template you can adapt.
The Fields Every Payment Receipt Email Needs
Stripe’s own receipts, sent automatically after a successful charge, illustrate the baseline most payment tools already build toward. Stripe’s documentation notes that “each receipt contains a link to view it in a browser and a unique receipt number that’s useful when looking up payment information,” and that “receipts for subscription and invoice payments are itemized to include line items, discounts, and taxes.” That unique identifier and line-item breakdown are the backbone of any receipt, whether you’re extending a payment processor’s default email or building your own.
A complete receipt email needs:
| Field | What it shows | Example |
|---|---|---|
| Amount charged | The total the customer paid, with currency | $49.00 USD |
| Date and time | When the charge was processed | July 9, 2026, 2:14 PM |
| Transaction or receipt ID | A unique identifier for looking up the charge later | rcpt_1Nx7Hj2eZvKY |
| Line items | What was purchased, especially for multi-item or subscription charges | Pro plan (monthly): $49.00 |
| Payment method | Card brand and last four digits only, never the full number | Visa ending in 4242 |
| Merchant name | The business name the charge appears under on the customer’s statement | Coldletter, Inc. |
| Support contact | A reply-to address or link for billing questions | [email protected] |
The payment method field deserves its own rule: never show a full card number. Stripe’s charge object exposes only payment_method_details.card.last4, and Stripe’s API reference describes that field simply as “the last four digits of the card.” Build your receipt template around that same convention. Display the card brand and last four digits, not the complete number, even if your payment processor’s backend gives you access to more.
The merchant name field is easy to underrate. Card networks route disputes partly based on whether a customer recognizes the charge on their statement, and the name your payment processor sends to the card network (the statement descriptor) doesn’t always match your product’s brand name. If a customer knows your app as “Coldletter” but the charge appears as “CLDLTR INC” on their card statement, say so directly in the receipt: “Charged as CLDLTR INC on your statement.” That one line heads off a chargeback before it starts.
A receipt also belongs firmly in the transactional category of email, not marketing: it’s triggered by one customer’s action and sent to that one customer, not broadcast to a list. For the full breakdown of what qualifies as transactional email and why that classification matters for deliverability, that guide covers the taxonomy in more detail.
Send the Receipt the Moment Payment Clears
Receipts get read differently than marketing email, and the gap starts with expectation: the customer just paid and wants confirmation now, not sometime later today. Postmark, a transactional email provider, builds its infrastructure around that expectation, noting that unlike bulk promotional mail, “transactional emails are personalized and typically sent to individuals one at a time,” and that the company sends “transactional emails up to 4x faster than the competition.” Whatever provider you use, wire the receipt to fire directly off the payment event, not a batch job that runs on a delay.
In practice, that means triggering the send from a webhook (Stripe’s checkout.session.completed or payment_intent.succeeded, for example), not from a page load the customer might close before it finishes. Webhooks can fire more than once for the same event, so deduplicate by the charge or receipt ID before sending. Without that check, a retried webhook produces two identical receipts in the customer’s inbox, which reads as a double charge even when only one payment went through. If you’re deciding how to wire that trigger into your application, Coldletter’s guide to sending email programmatically covers the API and webhook patterns for firing a transactional send like this one.
Postmark’s transactional email guide also recommends keeping subject lines short, roughly fifty characters, stating the outcome directly rather than teasing it, and being precise about dates and amounts. A receipt reader is scanning to confirm a specific transaction, not browsing for content, so “Your payment of $49.00 was successful” outperforms something vague like “Thanks for your order!”
How Much Marketing Content a Receipt Can Carry
It’s tempting to use a receipt, which gets opened and read far more reliably than a marketing send, to also carry a discount code or a feature announcement. Some of that is fine. All of it stops being fine past a specific line: a message that mixes commercial and transactional content can lose its transactional classification if the promotional part dominates the subject line or appears before the transaction details in the body. Coldletter’s guide to transactional versus marketing email covers the exact test the FTC applies under CAN-SPAM and what changes once a message is reclassified as commercial.
The practical rule for receipts: put the transaction confirmation first, in full, before any promotional element. Keep the subject line about the payment, not the promotion. A single small block near the bottom (a referral link, a related product) is common practice and low risk. A hero banner promoting a sale above the receipt details is not.
A Copy-Paste Receipt Email Template
Adapt the placeholders to your product and payment provider.
Subject: Your payment of [Amount] was successful
Hi [First Name],
Thanks for your payment. Here’s your receipt.
Amount: [Amount] Date: [Date] Payment method: [Card Brand] ending in [Last 4] Description: [Plan Name or Product Name] Receipt ID: [Receipt Number]
[View receipt online →]
Questions about this charge? Reply to this email or contact [Support Email].
[Company Name]
Frequently Asked Questions
What is a receipt email?
A receipt email is an automated, transactional message confirming that a payment succeeded. It’s triggered by one customer’s completed transaction and sent only to that customer, listing the amount charged, the date, a transaction ID, and the payment method used. It functions as proof of purchase, not a request for payment.
What’s the difference between a receipt email and an invoice email?
A receipt confirms a payment that already happened. An invoice email requests a payment that hasn’t happened yet, typically with a due date and an amount owed. The functional difference is timing: invoices go out before payment, receipts go out after.
Should a receipt email show a customer’s full card number?
No. A receipt should show only the card brand and the last four digits, the same convention Stripe uses in its own API, where the relevant field is documented as “the last four digits of the card.” Showing a full card number in an email is an unnecessary security risk; the customer already knows which card they used.
How quickly should a receipt email be sent after a payment?
As close to instantly as your infrastructure allows, triggered directly by the payment event (a webhook such as Stripe’s payment_intent.succeeded) rather than a scheduled batch job. Customers expect confirmation within seconds of paying, and a delayed receipt reads as an uncertain or failed transaction even when the charge went through fine.
Can a receipt email include a discount code or promotional offer?
In small amounts, yes, but the transactional content must appear first and the subject line must describe the payment, not the promotion. If the promotional element becomes prominent enough that a recipient would reasonably read the subject line as an ad, the message risks losing its transactional classification under CAN-SPAM. Keep promotions secondary and placed below the receipt itself.
What should the subject line of a receipt email say?
State the outcome directly, something like “Your payment of $49.00 was successful,” rather than a vague line like “Thanks for your order!” Keep it short, around fifty characters, since the recipient is scanning to confirm a specific transaction rather than reading for content. Precision on the amount and outcome matters more than a clever hook.
Sources
- Stripe, “Receipts”
- Stripe, “Charge object” API reference
- Postmark, “Transactional Email”
- Postmark, “Transactional Email Best Practices”
I’ve spent my career building software at scale with a soft spot for email: deliverability, lifecycle campaigns, and getting messages to actually land. I started Coldletter to fix what bugged me about transactional and marketing email tools. I’m based in Vancouver.