We automated our own order follow-up. Here is what broke first.

The job: five things nobody should have to remember

When a client buys an audit, a training session or a managed subscription from us, five things should happen the moment the payment lands:

1. We get an email telling us who bought what.
2. The order is written to a log we can search later.
3. The buyer gets a confirmation with a link to a short intake form.
4. Their intake answers are saved next to the order.
5. If a payment fails, a subscription is cancelled, or a refund or dispute appears, we get a plain-language alert.

None of that is difficult in isolation. Done by hand, it depends on someone remembering at the right moment, which is exactly the kind of work that quietly slips. So we built it as a workflow in n8n, connected to Stripe and to this website, and we treated it as a rehearsal for the work we do for clients.

Bug one: the same order, twice

Our first live test produced two emails to us, two emails to the buyer, and two rows in the order log for a single one-dollar payment.

The cause was that one payment had two triggers. Stripe sends our workflow a webhook when a payment succeeds. Separately, the checkout page tells the workflow when the customer’s browser sees success, which gives a fast second path if the webhook is delayed. Both fired within moments of each other. Each one asked, “have we handled this payment yet?” and each got the answer no, because neither had finished.

Stripe’s documentation is explicit that webhook endpoints might receive the same event more than once and recommends logging the IDs of events you have processed. That advice is sound, but our duplicates were not Stripe retries. They came from our own second path, and a simple “have I seen this?” check cannot protect you when two runs are executing at the same time.

The fix has two parts. The webhook path now waits 20 seconds, so the browser path normally finishes first. More importantly, both paths fetch the payment from Stripe and stamp it as handled in the payment record itself. Whichever run gets there second sees the stamp and stops. On the second test we got exactly one set of emails and one log row.

Bug two: an ampersand that rewrote the form

The intake form sends its answers to the workflow as a URL-encoded body, with fields joined by an ampersand. WordPress, trying to be helpful, rewrites a bare & inside custom HTML into &. Our script quietly shipped the wrong separator, and the workflow received field names like #038;organization instead of organization. The answers arrived, but under garbled names, so they landed in the log in the wrong place.

We fixed it twice on purpose. The page now builds the separator from its character code so WordPress has nothing to rewrite. The receiving workflow also strips that prefix defensively, so a future edit to the page cannot silently break the log again. Fix the cause, and make the receiver tolerant of the symptom.

Bug three: not every payment is ours

The Stripe account behind this site also handles payments for other things we run. Once the webhook was live, every successful payment in the account triggered the workflow, including ones that had nothing to do with Launch AI Works.

Now each checkout carries a tag identifying this site, and the workflow ignores anything without it. Monthly renewals of the managed subscription are recognised as renewals: they produce a short note to us, not a second “welcome, here is your intake form” email to the customer. The fix is small. The cost of missing it would have been a confused customer in the middle of an otherwise good relationship.

What gets a human’s attention

Failed payments, cancelled subscriptions, refunds and disputes each trigger a plain-language email to us. Nothing in the workflow refunds, cancels or disputes anything on its own. Those are the moments when a person should be looking, so the automation’s job is to make sure that person finds out immediately.

What we would tell a client

1. Pick the one event that means “this really happened.” For us it is a succeeded payment. Key every downstream step to it.
2. Assume every step will run twice. Make running twice harmless, and record that a step is done in a place that every path can see.
3. Test with real traffic and a small amount of real money. Our two one-dollar payments found more than weeks of reviewing the design would have.
4. Keep people on the consequential decisions. Automate the noticing and the paperwork. Leave refunds and judgment calls to a human.

This is the same approach we take in a client engagement: understand the real process, build the smallest version that works, test it against messy reality, and keep a person in charge of anything that matters.