A useful payment-failure email tells the customer what needs attention and gives them a safe way to act. Design the message in Migma using approved billing facts, then have the billing and sending owners verify that those facts are still true when the email goes out.
This guide is published by Migma for SaaS and subscription teams reviewing payment notices. It focuses on message quality and state checks, not payment processing implementation. Official sources were checked on October 15, 2026. The sample copy is an original planning example and must be adapted to the business's actual billing policy.
Ask which state the message describes
A failed attempt is an event in the past. The invoice might still be unpaid, the customer might already have updated their payment method, or a later attempt might have succeeded. Those situations need different messages.
Before drafting, ask the billing owner to define the current state that makes a notice useful. Separate “a payment failed” from “the customer still needs to take an action.” Do not imply that service will stop today unless that outcome and date are confirmed.
Stripe's webhook documentation explains that event delivery order is not guaranteed and events can be delivered more than once. This is an implementation concern for the engineering owner, but it matters to the writer too: an old failure event alone should not become a current claim that the customer has not paid.
Give Migma an approved billing brief
Review the brand context, then supply the purpose, approved terminology, required fields, and action destination. Use synthetic sample values in the creative brief. The designer does not need card numbers, credentials, or private customer records to check readability.
Ask Migma for a plain, calm message. Put the issue and action before decorative content. Keep the support route visible, use a recognizable sender, and make the action label describe the destination. “Review payment details” is more informative than a vague “Continue.”
Do not add an automatic apology, blame the customer's bank, or diagnose the failure unless the billing system supplies an approved explanation. A message can honestly say that an attempt did not succeed without inventing the reason.
Use different copy for different actions
The following examples show how the reader's task changes the message. Replace the bracketed planning fields before sending; they are not production template syntax.
The customer needs to update payment details
“We couldn't complete the payment for [plan]. Please review your payment details in your account. If you recently updated them, open your billing page to check the current status.”
Use this version only when the billing owner confirms that the customer has an available action. Include the amount and currency when they are accurate and helpful. Avoid displaying a raw amount that has not been formatted for its currency.
The team is retrying and no action is required yet
“The latest payment attempt for [plan] did not complete. We'll try again according to the schedule shown in your billing page. You can review your details or contact us if you need help.”
A retry statement must match the configured process. Do not paste a generic deadline into every notice. If the next retry time is unknown or changeable, point to a reliable status page rather than presenting an estimate as a commitment.
The payment has already succeeded
Do not send the old failure notice merely because it was queued earlier. Have the workflow owner define the successful-payment outcome and the appropriate confirmation. This is a routing decision, not a sentence that the designer can repair inside the stale email.
Choose one notice owner
The Loops payment-email guide describes Stripe-provided notices, event-driven Loops workflows, and server-triggered transactional email as different routes. Its current documentation also distinguishes workflow unsubscribe behavior from transactional sending.
Confirm which route your team uses and what it is responsible for. A branded workflow and a Stripe notice should not accidentally make conflicting claims about the same invoice. Keep marketing permission and account-service requirements with the responsible policy and platform owners; this guide is not a reason to route promotional copy around an unsubscribe.
Migma can provide the reviewed creative through HTML download. The implementer adapts it to the destination's supported template format and fields. This workflow does not assume a native Migma-to-Loops or Migma-to-Stripe billing connection.
Review the received message, not only the preview
Run Email Preflight on the Migma draft. Check important links, wording, layout, and light and dark previews. A passing creative check cannot establish invoice state, provider acceptance, or inbox placement.
Have the sending owner test the final destination message with controlled billing examples. Check a long plan name, missing optional name, different currency formatting, and a customer who pays during a wait. Follow the action from the received email and confirm that it reaches the intended billing page.
Also test a repeated event and an older failure arriving after a success. Record what should happen and what actually happened. The engineering owner should reconcile duplicate or out-of-order events without asking the copywriter to hide them with more general language.
Keep the message tied to its policy
Save the approved copy, billing policy owner, destination template version, and test outcomes together. Recheck the notice when retry timing, service access, or the payment-update destination changes.
Create the message in Migma once the facts and next step are clear. A useful billing email earns trust through an accurate state, a readable design, and an action the customer can complete.
Frequently Asked Questions
Is a failed-payment event proof that an invoice is still unpaid?
No. A later attempt may have succeeded. The billing owner must verify current state and define whether a queued notice should still send.
Can Migma decide the retry schedule?
This guide uses Migma for reviewed creative. The billing system and its responsible owner determine retry timing, service access, and invoice state.
Why check for two notice owners?
Stripe-provided notices and another sending workflow may both be active. Assign responsibility so the customer does not receive conflicting instructions for one invoice.
Which test matters after payment succeeds?
Test a customer who pays during a wait and an old failure arriving after success. The workflow should follow the approved current-state rule, rather than send a stale failure claim.