Make.com Automated Invoicing Setup -- 2

@larencea30

Hi, A couple things I'd want to confirm before locking in the build. What e-commerce platform is this, Shopify, WooCommerce, or something custom, since that decides whether I use an existing Make module or a custom webhook. Also, what Make plan are you on, since true instant triggering on checkout needs a webhook based watch, not polling, and that depends on your plan tier. For the PDF itself, since you mentioned no extra paid add ons, I'd go with a Google Docs template merged with your order data through Make's native Google Docs module, then exported to PDF. That keeps everything inside your existing Make account with no third party PDF service subscription needed. I'll map every customer, product, tax, and payment field cleanly, and build in a filter so failed payments don't trigger an invoice. Worth deciding together how you want partial refunds handled too, edited invoice, cancelled and reissued, or a separate credit note, since that changes the scenario logic a bit. Once built I'll walk you through turning it on and off, editing fields, and adding future triggers, either a quick video or a short doc, whichever you prefer. Ready to start once I know your platform and plan details.

@ronakkataria1

Two things about invoicing on a checkout webhook that are worth getting right the first time, because both of them show up as angry customer emails rather than as errors in Make. Duplicate invoices. Every payment provider retries a webhook if your endpoint does not answer with a 2xx quickly enough, and Make scenarios that do PDF generation inline can easily run past that window. The retry arrives, the scenario runs again, the customer gets invoice number two for the same order. Fix is an idempotency check.. store the order id in a Make data store, look it up as the very first module, exit quietly if it is already there. Wrong event. On most stores the order created event fires before the payment is actually captured. Invoice on that and you bill people whose card then declines. I hook the payment succeeded or order paid event instead, so an invoice only ever exists against money that arrived. Beyond that it is straightforward. Webhook in, router for the three payloads, field by field mapping, HTML template rendered to PDF so the layout is version controlled rather than trapped in a Google Doc, invoice number from a counter you control, and the PDF filed and emailed. Blueprint exported so you own it. Question.. which platform is the store on, and do invoice numbers need to be sequential with no gaps for tax reasons? Ronak

@PATEL0487

Hello, I am interested in working on your full-stack development project. I can build and maintain responsive, user-friendly web applications with clean and organized code. I will carefully understand your requirements, implement the required features, test the application, and deliver the work within the agreed deadline. I focus on quality, reliability, and clear communication throughout the project. I am ready to discuss your requirements and start working. Thank you.

@ii039

INR 1,500 for one store, one checkout workflow and one editable invoice template, with delivery in 3 days after API/payload scope, account access and the funded Freelancer milestone are confirmed. Plan: accept the paid-order event, validate required fields, map customer/address/item lines/tax/totals/payment method, and generate the PDF through modules available in your existing account. I would check a Google Docs template/export route first; no paid add-on will be enabled. We must confirm your store trigger, Make limits and PDF route before award. I will use a stable order/payment key and recorded processing state to prevent duplicate invoices, handle retries carefully, stop on incomplete/failed payments, and apply your agreed partial-refund/credit-note policy. Tax values come from your approved store data, not invented tax rules. Deliverables: blueprint/live scenario, editable template, field mapping, test evidence and concise on/off/edit instructions. Tests cover a paid multi-item order, repeated event, failed payment and partial refund; PDF fields/totals and actual latency will be checked. Use a sandbox/test order, not a real charge. AI/Codex will perform substantial design, implementation and testing; no claim of previous paid Make deployments. Please confirm AI-assisted work is acceptable. Which shop platform, sample payload, current Make plan and invoice numbering/refund rules do you use?