Payment confirmation email: confirm only what actually happened

The payment confirmation answers one question for a nervous customer: did my payment go through? It should say yes, say how much, and nothing else.

When it fires

On your payment provider's server-side success event. Never on the browser returning to your success page. Users close tabs and pages can be requested without a payment.

Workflow

1. The provider calls your webhook with a payment-succeeded event.
2. Verify the provider's signature, load the order, and check it is not already marked confirmed.
3. Mark it confirmed.
4. Send the email.

Implementation (Python 3)

import os
import requests

API = "https://api.inboxili.com/api/v1/transactional/send"

def send_payment_confirmation(order):
    resp = requests.post(
        API,
        headers={"Authorization": f"Bearer {os.environ['INBOXILI_API_KEY']}"},
        json={
            "to": order.customer_email,
            "from_email": "billing@yourdomain.com",
            "from_name": "Acme",
            "subject": "Payment received: {{amount}}",
            "html_body": "<p>We received your payment of <strong>{{amount}}</strong> on {{date}} for order {{order_id}}. Reference: {{reference}}.</p>",
            "text_body": f"Payment of {order.amount_display} received for order {order.id}.",
            "template_data": {
                "amount": order.amount_display,
                "date": order.paid_at.strftime("%Y-%m-%d"),
                "order_id": order.id,
                "reference": order.payment_reference,
            },
        },
        timeout=10,
    )
    if resp.status_code == 429:
        raise RetryLater()  # your job runner re-queues with backoff
    resp.raise_for_status()
    return resp.json()["message_id"]

RetryLater is your own exception. The rate limit is 120 requests per minute per key, so a burst of confirmations after an outage can hit it. Queue the sends rather than calling inline from the webhook handler.

Sample email

Subject: Payment received: $49.00 We received your payment of $49.00 on 2026-10-07 for order A-1042. Reference: pi_3Nx.

Things that go wrong

• Confirming before capture. Authorisation is not payment.
• Sending from the redirect page.
• Webhook redeliveries producing duplicates. Guard on the order's confirmed state.
• Putting card details in the body. Last four digits at most, and only if you need them.

Delivery events

A bounced payment confirmation should surface in your admin tools, because the customer may now believe the payment failed.

Deliverability notes

Transactional finance mail is trusted when it is consistent. Use one From address and one subject pattern.