build.allanninal.dev

Part 5 of 7 · Cart recovery series ~5 min read

How a cart recovery stops on checkout

A reminder lands in a shopper’s inbox at 8:03am. The linen shirt and the candles are still in the cart. They click through and buy. What happens next is the most important thing the whole system does: nothing. No third email, no “thanks for finally paying.” This post walks through how the chase stops the moment a shopper checks out — and the three ways a human can stop it by hand: suppress one cart, unsubscribe an email, write it off.

Key takeaways

  • A checkout event flips the cart to bought and cancels its wake-up — no reminder goes out.
  • Three owner actions: suppress (stop one cart), unsubscribe (stop an email), write off (close it out).
  • Each action updates the cart list and writes an audit row.
  • The shopper’s own unsubscribe link is the same path as the owner’s unsubscribe action.
  • Every stop is recorded so you can always see why a cart went quiet.

The automatic stop, plus three by hand

The automatic stop on checkout, plus three manual actions A diagram showing one input on the left flowing into three action paths, with an audit box on the right. Far left: a "Checkout or owner view" box showing the moment a checkout event lands or the owner opens the day's cart list, with three owner controls below: Suppress, Unsubscribe, Write off. The automatic path and the owner taps one. The middle column shows the three branches. Branch one, Suppress: stops reminders on a single cart; a Function URL Lambda flips the cart's status to closed in the cr-state DynamoDB table and cancels its scheduled wake-up, leaving the email's other carts untouched. Branch two, Unsubscribe: stops reminders for an entire email; the Function URL Lambda adds the email to the unsubscribe list, which the do-not-disturb gate reads on every send; this is the same path the shopper's own one-click unsubscribe link takes. Branch three, Write off: closes out a cart the owner has decided not to chase; the Lambda marks it closed with a written-off reason and cancels the wake-up. The right side shows the convergence: every action, plus the automatic stop on checkout, writes a row to the cr-audit DynamoDB table with timestamp, cart id, action, by-user, and notes. A note at the bottom: a checkout stops the chase automatically — the manual actions exist for the cases a human needs to step in. Checkout or view auto-stop on buy [Suppress] [Unsubscribe] [Write off] Action 1 Suppress • Stops one cart only • cr-state → closed • Wake-up cancelled • Other carts untouched Action 2 Unsubscribe • Stops reminders for a whole email • Same path as the shopper's own link Action 3 Write off • Close a cart you won't chase • Marked closed with a written-off reason Audit trail DynamoDB cr-audit timestamp · cart_id action · by-user notes A checkout stops the chase automatically — the manual actions are for when a human steps in.
Fig 5. The automatic stop on checkout, plus three manual actions. Suppress stops one cart. Unsubscribe stops an email. Write off closes a cart the owner won’t chase. Every stop, automatic or manual, writes to the audit trail.

The automatic stop (the one that matters most)

The whole point of the system is that it disappears the moment it’s no longer needed. When a shopper checks out, your store posts a checkout event to the same webhook from Part 2. The intake Lambda finds the matching cart row, flips its status in cr-state to bought, and cancels the scheduled wake-up. If a wake-up somehow still fires — the cancel and the buy raced — the “bought or unsubscribed?” check from Part 3 catches it and routes to still shopping, so no reminder goes out either way.

This is the single most important rule in the design. A shopper who just paid you should never get an email implying they didn’t. Belt and braces — the status flip and the wake-up check both guard it — because the cost of getting it wrong is a customer who feels nagged the instant after they bought.

Action 1: suppress (stop one cart)

Sometimes a cart shouldn’t be chased even though it’s technically open. The shopper called and said they’ll pay by invoice. The order’s being handled offline. The cart is a test the owner placed themselves. The owner opens the day’s cart sheet, finds the row, and taps Suppress.

Suppress submits to a Function URL Lambda. Two things happen: the cart’s status in cr-state flips to closed, and its scheduled wake-up is cancelled. Crucially, suppress is scoped to one cart — the same shopper’s other carts, now or later, are untouched. It’s the narrowest stop available, for the case where this one cart is the exception.

Action 2: unsubscribe (stop an email)

When a shopper clicks the unsubscribe link in a reminder, that’s the same action as the owner choosing Unsubscribe on a row — both add the email to the unsubscribe list. The do-not-disturb gate from Part 4 reads that list on every single send, so once an address is on it, no reminder ever reaches it again, for any cart, now or in the future.

The shopper’s one-click link and the owner’s button hitting the same path is deliberate. There is exactly one unsubscribe list and one way onto it, so “did this person opt out?” always has a single, honest answer. An unsubscribe is forever unless the shopper themselves opts back in; the system never quietly re-adds anyone.

Action 3: write off (close it out)

Some carts are simply not worth chasing. A $4 cart of out-of-stock items. A cart from an address that’s bounced before. A duplicate. Write off closes the cart out: the Lambda marks it closed in cr-state with a written-off reason, cancels any wake-up, and that’s the end of it. Unlike suppress (“don’t chase this, but it’s a real cart”), write-off is the owner saying “this cart was never going to convert.” The distinction matters for the monthly summary in Part 6, which counts written-off carts separately so the recovery rate isn’t dragged down by carts nobody ever meant to chase.

Every stop is logged, every stop is clear

The cr-audit table records every stop — the automatic one on checkout and all three manual ones — with the user (or “system” for the automatic stop), the timestamp, and a snapshot of the cart row before and after. Two months from now, when someone asks “why did this cart never get a second reminder?”, the answer is one lookup away: bought on the 14th, or written off by Sam on the 15th, or unsubscribed by the shopper at 9:02am. No mystery, no guessing.

This kind of clarity is what lets the owner trust the system to run unattended. The reminders go out on their own, the stops happen on their own, and when a human does want to know what happened, the trail is right there.

Next post: the cost breakdown. The whole pipeline above runs in coffee-money territory at SMB volume; Part 6 explains exactly where the dollars go and why.

All posts