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.
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.