MailInApp turns a cart-recovery email into a place to actually finish checking out — a real Buy Now button, an honest countdown on the discount, and an optional spin-to-win nudge. No code, no separate storefront to maintain.
A recovery email that only links back to your store makes someone start over: find the item again, rebuild the cart, check out separately. Every extra step there loses people. With MailInApp, the Product block's Buy Now button, the Countdown block's always-accurate timer, and an optional Spin-to-win reward all live directly inside the recovery email itself.
Where the "abandoned" data comes from
MailInApp doesn't run its own storefront or track carts on its own — it doesn't need to. Whatever system already knows a cart was abandoned (your store platform, a CRM, a spreadsheet export) becomes a MailInApp data source, either connected live over an API or refreshed on a schedule. From there, a recurring send re-evaluates an audience filter like "cart abandoned 1-24 hours ago" against that data source's current rows on its own cadence. It sends only to matches not already covered by a previous recovery email — the same rolling-window pattern used for post-support-ticket surveys.
The blocks built for winning the sale back
- Product — a real Buy now button, charging through your own connected Stripe account. Set the discounted price (or the original one) once and it's accurate for every send — no separate checkout page to build.
- Countdown — if the recovery offer is time-boxed, the countdown redraws itself fresh on every open, so "expires in 2 hours" is never a stale number by the time someone actually reads the email.
- Spin-to-win — an optional game-layer nudge that hands out a small reward for finishing checkout, on top of or instead of a plain percentage-off code.
- Carousel — remind the recipient exactly what they were looking at with a swipeable gallery of the abandoned items.
Building a short recovery sequence, not just one email
One recovery email is a start; a short sequence usually recovers more. A recurring send only reaches audience-filter matches it hasn't already covered, so a second email — say, "still hasn't purchased, abandoned 3+ days ago" — reaches only the people who still need that next nudge. There's no manual list-juggling required to keep the two sends from overlapping.
What happens when the Buy Now button is tapped
The button link-first opens a real Stripe Checkout Session on your own connected Stripe account and redirects there for payment — MailInApp never holds funds or sees card details. A completed sale rolls into the same orders and analytics dashboard as any other MailInApp purchase, so a recovered sale is easy to tell apart from a fresh one if you're tracking recovery-campaign performance specifically. (If your store platform already restores the shopper's own cart session at checkout, the Product block's Checkout field can instead be set to Link to external store checkout and pointed at your store — worth weighing against the "start over" cost the opening paragraph describes, since MailInApp's own orders/inventory tracking above doesn't apply once checkout happens off-platform.)
What if the recipient's inbox can't show the countdown or the spin wheel?
Every block still gives a working path to the same outcome. Where the countdown animation can't display, a plain number takes its place; where the spin wheel can't display, the same tap-through reward link shows up as a plain button instead of an animated wheel. The sale itself is never gated behind an animation only some inboxes can show — see how the fallback engine works for the full picture.
Getting started
Connect the data source that already knows which carts were abandoned — an API connection, or a CSV you refresh on your own schedule. Then build the recovery email with a Product block and, optionally, a Countdown for a time-boxed discount. Set up a recurring send with an audience filter for "abandoned N hours/days ago" under Contacts & sending so the whole sequence runs on its own from there.