# Payment confirmation email: 12 examples and templates > Write clear, secure payment confirmation emails for purchases, subscriptions, renewals, deposits, refunds, and asynchronous payments—with original templates and production guidance. - **Category:** Transactional email - **Published:** August 4, 2026 - **Reading time:** 18 min read - **Author:** Maya Chen, Email infrastructure - **Canonical page:** [https://emailbump.com/blog/payment-confirmation-email-examples](https://emailbump.com/blog/payment-confirmation-email-examples) A payment confirmation email tells a customer that a specific payment completed and gives them enough evidence to recognize, reconcile, and question it. It should state the merchant, amount and currency, payment date, purchased item or billing period, reference, masked payment method, and a safe route to the receipt, invoice, account, or support. Do not send the message because a browser reached a success page. Redirects can be replayed, closed early, or arrive before an asynchronous payment finishes. Trigger the confirmation from a verified server-side payment event, make event handling idempotent, and distinguish succeeded, processing, failed, refunded, and disputed states in both subject and body. > **Payment confirmation is a factual message** > > State exactly what succeeded, for whom, how much, in which currency, and when. Do not call an authorization, pending transfer, created invoice, or submitted checkout a confirmed payment. ## Payment confirmation, receipt, and invoice are different ### Name the payment artifact correctly ```text ARTIFACT WHAT IT ESTABLISHES WHEN TO SEND Payment confirmation A named payment reached a succeeded state Verified success event Receipt Evidence of a completed payment/refund After success; requirements vary Invoice Amount requested or owed When invoice is issued Paid invoice Invoice plus recorded settlement After invoice payment succeeds Order confirmation Seller accepted or recorded an order Order state, not payment alone Processing notice Payment is submitted but not final Async method enters processing Refund confirmation A refund was initiated or completed Name the exact refund state One event may produce more than one artifact, but do not merge their meanings. ``` A payment confirmation can link to a provider-hosted receipt or a paid invoice. It is not automatically a tax invoice or legally sufficient receipt in every jurisdiction. Review local invoicing, tax, record-retention, and accessibility requirements with qualified advisers and your payment provider. ## What every payment confirmation email should include - Recognizable legal or trading name and a consistent sending domain. - Unambiguous succeeded state using words such as payment received or payment confirmed. - Amount and ISO currency, including tax, discount, credit, or balance context where relevant. - Payment completion date and timezone when it could affect reconciliation. - Product, order, invoice, workspace, or subscription the payment belongs to. - Stable customer-facing reference that support can search without exposing an internal secret. - Payment method brand and safely masked identifier when useful; never full card data or a security code. - Receipt or paid-invoice destination and a route to billing history inside the authenticated account. - What happens next: access, shipment, renewal date, remaining balance, or no further action. - Monitored support details for a payment the customer does not recognize. ## 12 payment confirmation subject-line examples ### ONE-TIME PURCHASE **Payment received for order NS-2048** Connects the state to a customer-facing order reference. ### SAAS SUBSCRIPTION **Your $49.00 USD Northstar payment is confirmed** Amount and product make the message recognizable. ### RENEWAL **Northstar renewed through September 4, 2027** Leads with the service consequence after successful payment. ### ANNUAL PLAN **Payment received: Northstar Pro annual plan** Names the plan and interval. ### PAID INVOICE **Invoice INV-2048 is paid** Uses paid only after settlement is recorded. ### DEPOSIT **We received your $500.00 USD project deposit** Does not imply the remaining balance was paid. ### INSTALLMENT **Payment 2 of 4 received for project NS-18** Shows sequence and remaining context. ### MARKETPLACE **Payment confirmed for your Cedar Studio booking** Names the seller or booking a platform customer recognizes. ### DONATION **Your $25.00 USD contribution was received** Avoids calling the message a tax receipt unless it meets applicable requirements. ### PROCESSING **Your bank payment is processing—not complete yet** Prevents a pending bank method from being mistaken for success. ### PARTIAL REFUND **$12.00 USD refund sent for order NS-2048** States the amount and refund action precisely. ### CORRECTION **Correction: receipt link for payment PAY-2048** Names the correction without changing the recorded payment state. ## Template 1: SaaS subscription payment confirmation ### SaaS payment confirmation template ```text Subject: Your [amount] [currency] [Product] payment is confirmed Hi [First name], We received your [amount] [currency] payment for [Workspace]’s [Plan] plan. Payment date: [date and timezone] Billing period: [start date]–[end date] Payment method: [brand] ending in [last digits] Reference: [customer-facing reference] Your plan remains active through [date]. No action is required. [View receipt] [Manage billing] Don’t recognize this payment? Contact [monitored support channel]. ``` Choose the billing owner from current account state and include the workspace when one person manages several accounts. Link to authenticated billing history as the durable source of truth. If the provider’s receipt URL expires or requires re-verification, do not imply it is a permanent public document. ## Template 2: one-time order payment ### Order payment confirmation template ```text Subject: Payment received for order [order number] Hi [First name], Your [amount] [currency] payment for order [order number] was received on [date]. [Item] × [quantity] [line amount] [Tax / shipping / discount] [amount] Total paid [amount currency] Payment method [masked method] Next: [fulfillment state and realistic timing]. Payment confirmation does not mean the order has shipped. We’ll send tracking when the carrier accepts it. [View order and receipt] [Get help] ``` Keep payment and fulfillment states separate. The customer should not read payment received as shipped, delivered, or guaranteed inventory. If the order can still be reviewed or cancelled, state that next state plainly. ## Template 3: deposit or installment ### Partial payment confirmation template ```text Subject: We received your [amount currency] [deposit/installment] Hi [First name], We received [amount currency] toward [project, booking, or invoice]. Invoice: [invoice reference] Total: [total currency] Paid to date: [paid currency] Remaining balance: [balance currency] Next due date: [date, or no balance due] [View payment record] This message confirms only the payment shown above. [Explain the next service, reservation, or billing step without overstating what is guaranteed.] ``` A partial payment template must preserve the denominator. Showing only the amount received can make a deposit look like full settlement. Calculate paid-to-date and balance from the authoritative ledger rather than template arithmetic based on an event payload. ## Template 4: asynchronous payment processing ### Payment processing email template ```text Subject: Your [payment method] payment is processing Hi [First name], Your [amount currency] payment for [order/invoice] was submitted, but it is not confirmed yet. [Payment method] can take approximately [provider-supported range]. Current status: Processing Reference: [reference] Submitted: [date and timezone] Do not submit another payment while this one is processing. We’ll email you when it succeeds or if action is required. [View current status] ``` This is intentionally not a payment confirmation. Some bank debits, transfers, vouchers, and regional methods settle after checkout. Stripe’s receipt documentation, for example, notes that paid-invoice receipts are sent after payment completes and can be delayed for asynchronous methods. ## Template 5: refund confirmation ### Refund email template ```text Subject: [amount currency] refund sent for [order/reference] Hi [First name], We submitted a [amount currency] [full/partial] refund for [order/reference] on [date]. It is returning to [masked payment method]. Original payment: [amount currency] Refund amount: [amount currency] Remaining paid amount: [amount currency] Refund reference: [reference] Your bank or payment provider may take [supported range] to display the credit. [View refund receipt] [Contact support] ``` Use sent, initiated, or completed according to the processor state. Do not guarantee when the customer’s bank will display funds unless that timing is contractually reliable. A partial refund needs the original amount, refund amount, and remaining paid amount. ## Trigger confirmations from verified payment events ### Reliable payment-email pipeline ```text PAYMENT PROVIDER signed payment-succeeded event | v WEBHOOK HANDLER verify raw-body signature -> persist event ID -> acknowledge quickly | v PAYMENT LEDGER TRANSACTION reconcile amount/currency/account -> update state -> insert unique email intent | v EMAIL WORKER re-read authoritative payment -> render -> send with idempotency -> store message ID | v DELIVERY EVENTS delivered / bounced / complained -> support-visible message ledger ``` - Verify the provider signature against the exact raw webhook body before trusting fields. - Deduplicate the payment event and enforce one confirmation intent per payment-state transition. - Retrieve or reconcile the current payment object when event ordering can be delayed or reversed. - Use amount and currency together; never infer currency from account defaults or display locale. - Commit payment state and email intent atomically, then let a durable worker own submission retries. - Treat an email API timeout as ambiguous because the provider may have accepted the message. - Keep the provider payment ID internal and expose a separate support-safe reference where possible. ## Protect payment and account data Never place a full payment-card number, card verification code, bank credential, API key, private invoice object, or reset token in an email. Display only the minimum masked method detail needed for recognition. Keep sensitive account and billing changes behind an authenticated session rather than a powerful email link that performs the action immediately. Email content can appear on lock screens, shared devices, forwarding rules, support tickets, and compromised mailboxes. Decide whether addresses, tax identifiers, line items, recipient names, and subscription details are necessary for recognition. Apply the organization’s PCI DSS, privacy, retention, and incident requirements to the complete path, including templates, logs, webhooks, analytics, support tools, and backups. ## Keep promotions out of the payment evidence A receipt is a poor place to hide an upsell. It makes the payment evidence harder to scan and can change how a mixed-purpose message is classified. Google explicitly advises not mixing promotions into sales receipt messages. Send an eligible follow-up separately when the person’s consent, timing, and customer state support it. The FTC describes messages that complete or confirm an agreed transaction as transactional or relationship content, but treats mixed messages according to primary purpose, including subject and placement. Other jurisdictions use different rules. Keep factual payment content first and obtain qualified legal guidance for the markets you serve. ## Payment confirmation production checklist - Send only after a verified succeeded event—not a browser redirect or unverified client callback. - Confirm amount, currency, merchant or workspace, payment state, and customer before rendering. - Make event handling, message-intent creation, and provider submission safe against duplicates. - Render absolute dates and timezones; localize currency without changing its actual code. - Mask payment methods and remove secrets or unnecessary personal and financial data. - Keep receipt, invoice, order, fulfillment, refund, and payment states distinct. - Provide plain text, accessible HTML, a recognizable sender, and monitored support. - Test success, duplicate event, async processing, partial refund, full refund, and out-of-order events. - Store message IDs and delivery outcomes where billing support can search them. - Keep promotional content out of the confirmation and protect critical billing traffic operationally. ## Frequently asked questions ## What is a payment confirmation email? It is a transactional message confirming that a specific payment reached a succeeded state. It normally identifies the merchant, amount, currency, date, purchase or billing period, reference, masked method, and next step, with access to a receipt or paid invoice when available. ## Is a payment confirmation the same as a receipt? Not necessarily. A confirmation communicates payment state; a receipt is an evidence artifact that may have provider, tax, or jurisdiction-specific fields. A confirmation can contain or link to a receipt. Confirm the requirements that apply to the transaction rather than relying on the email’s title. ## When should payment confirmation email be sent? Create it after the backend verifies the payment provider’s successful state. For asynchronous methods, send a processing notice first if useful, then the confirmation after settlement. Do not trigger it from the checkout success page because the browser is not authoritative payment evidence. ## Should payment emails include an unsubscribe link? A narrowly factual message that confirms an agreed transaction may be treated differently from commercial marketing, depending on applicable law. Customers generally cannot opt out of essential payment evidence needed to operate the account, but promotional content and optional billing education should follow their own eligibility and unsubscribe policy. Obtain legal advice for your jurisdictions and use case. ## Send billing email through an observable transactional API Email Bump accepts product messages over REST or SMTP and carries their delivery events beside campaigns, contacts, consent, inbound replies, and lifecycle flows. - Server-side REST and SMTP submission - Delivery, bounce, and complaint webhooks - HTML, plain text, templates, and metadata [Learn more](https://emailbump.com/docs/transactional-api) ## Build the complete billing-message path - [Stripe webhook email](https://emailbump.com/blog/send-emails-from-stripe-webhooks) — Turn payment events into effective-once email without losing or duplicating work. - [SaaS email marketing](https://emailbump.com/blog/saas-email-marketing) — Connect payment, renewal, recovery, activation, and retention messages by state. - [REST email API](https://emailbump.com/blog/send-email-rest-api) — Add secure submission, timeouts, idempotency, retries, and delivery webhooks. - [Order confirmation templates](https://emailbump.com/blog/order-confirmation-email-templates) — Keep order acceptance, payment, fulfillment, pickup, and shipping states distinct. ## Sources - [Stripe receipts and paid invoices](https://docs.stripe.com/receipts) - [Stripe webhook signatures](https://docs.stripe.com/webhooks/signature) - [PCI Security Standards Council FAQ](https://www.pcisecuritystandards.org/faq/) - [FTC CAN-SPAM compliance guide](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business) - [Google email sender guidelines](https://support.google.com/mail/answer/81126)