Flyout

I sell a paid Mac app directly, no App Store, and no server of mine that the customer ever talks to. Payment goes through Stripe, the license is signed and emailed automatically, and the app verifies it offline. Total infrastructure: one Cloudflare Worker, one SQLite database on D1, and Amazon SES for the email.

The pipeline, in order:

1. Stripe Payment Link. No custom checkout page.

2. Stripe fires checkout.session.completed at the Worker.

3. The Worker signs a license key with an Ed25519 private key held as a secret.

4. It writes a row to D1: email, key, session id, payment intent id.

5. SES sends the key to the buyer.

6. The app verifies the signature locally against an embedded public key. No call home, works on a plane.

That is a few hundred lines. The interesting part is that all three bugs I hit were silent. Nothing threw, nothing showed up in logs, and the happy path kept working while specific customers got nothing.

Bug 1: checkout.session.completed does not mean you were paid.

It means checkout finished. With delayed payment methods the session arrives with payment_status 'unpaid' and the money settles days later, or never. Deliver straight off the event type and you hand over the product before you have been paid. The fix is one line: check payment_status explicitly and refuse otherwise. I found this reading the docs while chasing something else, not because anything broke.

Bug 2: The Stripe SDK does not work on Workers out of the box.

Its default HTTP client is Node's http module, which does not exist in the Workers runtime. You have to pass httpClient: Stripe.createFetchHttpClient(). Miss it and you fail at request time, in production, inside the webhook handler, which is the one place nobody is watching.

Bug 3: SES's suppression list drops mail without telling you.

If an address is on your account level suppression list, SendEmail still returns a MessageId and a 200. Your code believes it sent. Nothing sent. In my case the address had been on that list for years because of one stale bounce from a completely different context. So the first thing I check now when someone says the email never arrived is the suppressed destination for that address, with get-suppressed-destination in the sesv2 CLI.

The other piece worth stealing: make delivery idempotent and call it from two places. My fulfillment function runs from the webhook and also from the thank-you page, which asks for the receipt using the session id. Whichever arrives first wins, and the race is settled by a UNIQUE constraint on the session id in D1. The webhook can be slow or fail outright and the buyer still sees their key the moment they pay. Before that, a late webhook looked exactly like a broken purchase to someone who had just handed me money.

The theme, if there is one: with no backend there is nothing to monitor, so every failure mode I hit was something that returned success and quietly did nothing. Every guard I have added was for a bug that produced no error.

For anyone running something similar: what else silently succeeds in your stack? I would rather add the guard now than hear about it from a customer.