An order confirmation email has one immediate job: reassure a customer that the purchase worked and show what happens next. It also has to handle long product names, discounts, split shipments, taxes, gift messages, missing images, and support links—often with data that the designer never sees in a neat mockup.
Emailify lets teams design in Figma and export responsive HTML, but reliable transactional email starts with state planning rather than a single ideal receipt.
Define the confirmation contract
Write down what the email confirms and what it does not. A payment-authorized order may not yet be fulfilled. A marketplace order may have multiple sellers. A pickup order has different next steps from delivery.
Agree on the minimum information with ecommerce, support, engineering, legal, and email operations:
- order identifier and date;
- purchased items, options, quantity, and price;
- subtotal, discounts, shipping, tax, credits, and total;
- payment method shown at an appropriate level;
- delivery, pickup, or digital-access expectation;
- address or collection location where appropriate;
- order-management and support paths;
- required business and compliance details.
The subject line and preheader should confirm the event without exposing sensitive data. The email body should not promise shipment if the actual state is merely “order received”.
Design modules around variable data
Start with the longest plausible values, not the cleanest sample order. Test a long product title, several variants, a two-line address, a large quantity, multiple discounts, and currencies with different symbol placement.
Useful modules include:
- status header;
- order summary;
- repeatable line item;
- totals stack;
- delivery or pickup information;
- next-step callout;
- support and footer content.
Set expectations for missing product images and unavailable links. If an image is optional, the layout should close the gap cleanly rather than leave a broken placeholder. If the customer cannot manage the order after a cutoff, the button label and fallback text should explain that.
For broader component guidance, see Figma email components. The order-confirmation version needs extra discipline because its modules are populated by transactional data rather than a marketer’s final static copy.
Map design content to the sending system
Create a field map alongside the Figma design. For every dynamic value, document:
- the visible example;
- the system field or merge tag;
- formatting ownership;
- empty-state behavior;
- maximum expected length;
- whether the value can contain user-entered text.
Do not leave placeholder labels such as {total} for email ops to interpret. Specify whether the value includes currency, how tax labels vary, and what happens when a discount or shipping row is absent.
Treat user-entered gift notes and addresses as untrusted content. The implementation must escape or sanitize values according to the sending platform; visual design alone cannot make arbitrary input safe.
Build responsive HTML with honest fallbacks
Use Emailify’s email components and responsive controls to assemble the approved modules, then export production-ready HTML for the team’s sending platform. Keep layout choices conservative around critical purchase data. Decorative treatments can degrade; the order number and total cannot.
For narrow screens, decide what stacks and what stays aligned. A multi-column product row may become image-plus-details with the price beneath. Totals should remain easy to scan. Buttons need sufficient size and spacing, while essential URLs should still make sense if styles or images fail.
Add meaningful alt text to informative images and empty alt text to decoration. Use live text for essential details rather than baking the receipt into an image. The email accessibility checklist provides a broader review framework.
Test a state matrix, not one sample send
Create test payloads for the combinations your store actually produces:
- one physical item;
- many line items;
- digital-only order;
- local pickup;
- free shipping and paid shipping;
- discount code, gift card, and store credit;
- tax-inclusive and tax-exclusive markets;
- refunded or zero-value total where supported;
- missing product image;
- unusually long name, address, and item title.
Send rendered tests through the real platform. Previewing exported HTML is useful, but the ecommerce or ESP layer can alter markup, merge tags, links, and tracking. Check major email clients and mobile widths that matter to the audience, including Outlook where appropriate.
Review the message as customer support would
Ask a support teammate to answer these questions using only the email:
- Did the order succeed?
- What exactly was purchased?
- What was charged and how was the total formed?
- Where is it going, or how is it collected?
- What happens next and when?
- How can the customer correct a problem?
Ambiguity here creates avoidable tickets. A visually elegant summary that hides the delivery expectation or discount calculation is not complete.
Before release, verify every button and fallback URL, confirm the reply-to behavior, check plain-text output, and ensure analytics parameters do not break authenticated order links. Use test accounts and non-sensitive data.
This workflow differs from a broad transactional email design system: it goes deep on the purchase record, variable order data, and the reassurance customers need immediately after checkout. Emailify removes the hand-coding bottleneck between Figma and HTML. The ecommerce team still owns state accuracy, safe data insertion, and tests from the real sending system.
Read as Markdown Related resource index Site index for AI agents
Pro Bundle