The purchase webhook writes to Stripe before it writes to any inbox

When a client buys a package — a mixing session, a software build, an accessibility audit — Stripe fires a payment_intent.succeeded webhook. The handler does four things in order. First it verifies the Stripe signature using the raw request body so tampered payloads are rejected before any logic runs. Second it reads the PaymentIntent metadata for a field called emailSent. If the value is true, the handler returns immediately. This is the idempotency check. Stripe retries webhooks. Serverless functions cold-start. Without this check, a client could receive two identical confirmation emails. Third — and this is the key — it writes emailSent true back to the PaymentIntent metadata before sending a single email. If two webhook deliveries hit simultaneously, only the one that wins the metadata update race proceeds. The loser reads emailSent as true on its next check and exits. Fourth it sends two emails through Resend. The customer gets an order summary — package name, price, delivery estimate, and a three-step guide: book your consultation, discuss the project, I deliver. If they left a message during checkout, it is quoted in the email. The reply-to is my personal email so they can respond directly. I get a separate notification with the customer name, email, product, their message, and a direct link to the Stripe dashboard payment page. Both emails are plain text. Both are wrapped in independent try-catch blocks. If the customer email fails, I still get notified. If my email fails, the customer still gets confirmation. Two emails, two catch blocks, one metadata field, zero duplicates.