Lemon Squeezy + Resend Setup and Webhook Spec for Existing AI Tool Shop

Lemon Squeezy + Resend specialist needed to configure and specify the commerce layer for my AI tool shop. Please read the scope carefully before applying — this is a configuration, specification and testing engagement, not a build. If you are looking for a coding project this is not it, and I would rather not waste your time. THE SITUATION I sell a suite of proprietary AI business-building tools, hosted on Vercel. The licensing and access system is already built and working: a gate wraps every tool, a self-hosted licence store on Vercel KV resolves who can access what, and there is a proven admin endpoint that issues licences. Tiers already support single tools, bundles, multi-tool suites and trials. What's missing is the bridge. There is no purchase-to-licence automation at all — every licence to date has been issued by hand — and no transactional email. Lemon Squeezy currently plays no part in access resolution. I am building that bridge myself. What I need is someone who genuinely knows Lemon Squeezy and Resend to configure both platforms properly and tell me exactly what to build. WHAT YOU WOULD OWN 1. LEMON SQUEEZY, end to end. Store settings, all products and variants with prices, bundles, subscriptions, discount codes, checkout configuration, webhook registration and API keys. My merchant account is active and connected to my bank. One thing to investigate early: Lemon Squeezy previously would not let me toggle test mode because a live order existed in the account, and some API keys were generated while in test mode. I need to know what payment testing is actually possible before it gets planned. 2. RESEND, end to end. Domain verification, SPF, DKIM and DMARC, sender identity, warming and deliverability, plus building the transactional templates themselves — purchase confirmation, licence-key delivery, bundle activation, subscription lifecycle and payment failure. These emails carry the product itself, so inbox placement in Gmail, Outlook and Apple Mail needs to be demonstrated, not assumed. 3. THE WEBHOOK SPECIFICATION. This is the deliverable I care most about. A written document I implement from, covering: which events to subscribe to and what each actually means in practice; real annotated payload examples rather than links to the docs; signature verification precisely; which field is the stable idempotency key and how their retries behave; retry and failure semantics including which status codes stop or trigger a retry; what should happen to access on refunds, cancellations and chargebacks; and the completed product-to-tier mapping table. Optionally, and worth more to me: a standalone reference implementation alongside the spec — a loose file, not connected to my repositories. I would review and integrate it myself. 4. ENVIRONMENT RECOMMENDATION. I run two repositories, one live and one test. They are not identical — different frameworks, different API handler paths. I would like your recommendation on safe payment testing after you have seen the structure. 5. THE TEST PLAN, and executing the test purchases against what I build. Purchases, bundle access, duplicate webhooks, failed payments, cancellations, subscription access. 6. DOCUMENTATION so I can add or activate a future product through configuration rather than coming back to you. WHAT YOU WOULD NOT DO Write code directly in my repositories. Lemon Squeezy has no code surface — it is dashboard configuration plus a webhook URL — so this split is clean rather than awkward. I integrate; you configure, specify and test. This is firm, and it is not about trust. These tools represent months of work and every change goes through a review process I run myself. SCALE Roughly 18 tools, several bundles and three subscription products need to exist in the configuration. Only three paid products go live initially — two bundles and one individual tool. Everything else stays configured but inactive until it clears testing. Two of the three launch products already map to tiers that work today, so there is a testable path from day one. TWO THINGS THAT AFFECT SCOPE My subscription products have no mechanism yet. Recurring access needs new work on my side before it can function at all, so please quote the subscription specification as a separate line item and I will sequence it independently. Two of my tools were renamed publicly but not internally. Mappings must use internal IDs, which I will provide. Using the public names would issue licences that match nothing and silently lock customers out. BEFORE YOU QUOTE — one question Have you integrated Lemon Squeezy, Stripe or Paddle webhooks before? If so, please name one thing about that platform's webhook behaviour that surprised you or caused a bug you had to fix. I would rather hear a specific war story than a list of technologies. WHAT TO SEND ME - A fixed-price quote, with subscription specification priced separately - An estimated timeline - Confirmation that the division of work above suits you - Any concerns about the architecture as described - What access you need to assess it accurately - Whether post-delivery bug fixes are included, and for how long I have a nine-page technical brief covering the architecture, the mapping vocabulary and five known defects in the existing system. I will share it once we confirm fit — it contains internal identifiers so I am not posting it publicly. OUT OF SCOPE: coaching enrollment, handled separately through ThriveCart. Shop and website design, handled by a separate Showit specialist.