Email for ecommerce storesReceipts, abandoned carts and winbacks without a per-profile bill.

A store's mail splits cleanly into two kinds of sending, and most platforms blur the pricing between them. The receipt, the shipping notice and the abandoned-cart nudge are triggered by one event, for one customer, and need to go out reliably within minutes. The winback, the promotion and the seasonal campaign go to a segment of the list on the store's own schedule, and can tolerate more variance in timing.

A profile-priced marketing cloud charges by how many people it has built a profile on, which usually means every visitor who lands on the site and gets fingerprinted, whether or not they ever buy or subscribe. The bill grows with traffic, not with the two jobs actually being done. A store running a big catalog with a lot of window shoppers pays for all of them.

The receipt and the abandoned-cart email both start the same way: a store event fires, and the app calls a transactional API with fixed recipients pulled from the order or the cart, not from anything a customer typed into a message. A checkout webhook that fires on cart abandonment can call the same API used for order confirmations, with different content and a delay built into the calling code.

• Order confirmation fires immediately on checkout, using a stored template with the order details merged in.
• Shipping notice fires when the fulfillment system emits a tracking event.
• Abandoned-cart nudge fires from a scheduled job a few hours after a cart is created with no completed order, using the same transactional path.
• Winback and promotional campaigns run separately, on a segment of the contact list, on the store's own send schedule rather than an event trigger.

1. Purchase and install. A single $199 payment covers the license, and the one-click Create stack link installs the platform into your own AWS account as its own stack.
2. Verify the sending domain. The app generates the DKIM, SPF and DMARC records; one click applies them if DNS runs on Route 53 in the same account, otherwise they are pasted into the store's existing DNS provider.
3. Send inside the SES sandbox first. A new AWS account starts limited to verified addresses, enough to test the order-confirmation and cart-abandonment flows before real customers see them.
4. Request production access, using the link the app provides to AWS's own form, ahead of the first real launch or promotional push rather than during one.
5. Create scoped API keys for the checkout and fulfillment systems to call, separate from the wider key used for campaigns and the contact list.

That table has no row for how many products are in the catalog or how many anonymous visitors browsed last month, because neither is billed. A store with a large catalog and a lot of quiet traffic pays for what it actually sends, and a seasonal spike during a sale costs more only because more mail actually went out, not because a tier boundary was crossed.

Serverless infrastructure behind the install scales automatically for a traffic spike, but sending reputation does not work the same way. A store that has been sending a steady trickle of transactional mail and then blasts a large promotional list on the day of a sale is asking a domain to absorb a volume jump it has not built reputation for. The fix is the same one that applies on any sending infrastructure: warm the domain and the list gradually in the weeks before a known peak, watch bounce and complaint rates on the way up, and treat the sale-day send as the top of a ramp rather than the first real test.

A store that needs deep behavioral segmentation, predictive send-time optimization, or an ecommerce customer data platform with product-level browse and purchase modeling built in is better served today by a platform built specifically for that, even with the per-profile bill that comes with it. That depth is a real feature some vendors have built years into, and it is not what a transactional-plus-campaigns install replaces.

It is also not the right move for a store that will not open an AWS account, or one that needs vendor-managed deliverability consulting as part of the plan. The install gives a store the API, the campaign tool and the account; the store runs the send strategy.