The latest articles on DEV Community by Lizard Gecko (@lizard_gecko_0126a0bcb606). https://dev.to/lizard_gecko_0126a0bcb606 https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4135298%2Fb914f235-4908-4bb9-bc9c-8a86c6270a87.png https://dev.to/lizard_gecko_0126a0bcb606 en Lizard Gecko Mon, 21 Sep 2026 08:24:24 +0000 https://dev.to/lizard_gecko_0126a0bcb606/my-payment-webhook-silently-failed-on-the-first-real-transaction-and-i-built-a-tool-to-catch-4i9d https://dev.to/lizard_gecko_0126a0bcb606/my-payment-webhook-silently-failed-on-the-first-real-transaction-and-i-built-a-tool-to-catch-4i9d <p>I spent four months building ApiPulse, an uptime monitor for APIs, solo, in the evenings. This week I launched it. The first thing I did was pay for it myself.</p> <h2> Why test with real money </h2> <p>Configuration looks correct right up until it isn't. So I made a real €5 purchase with my own card to walk the full chain: checkout, payment provider, webhook, plan activation in the app.</p> <p>The money went through. The payment provider confirmed it. My app still said <strong>Free plan</strong>.</p> <h2> The bug </h2> <p>The webhook endpoint was returning <code>401: Invalid webhook signature or payload</code>.</p> <p>I went through the usual suspects:</p> <ul> <li>Was the body parsed as JSON before signature verification? (That breaks HMAC, since the signature is computed over the raw bytes.) No — the route used <code>express.raw()</code> and the handler rejected anything that wasn't a Buffer.</li> <li>Was the signature header name right? Yes.</li> <li>Was the payload being re-serialized with <code>JSON.stringify</code>? No.</li> </ul> <p>The actual cause was boring: the webhook secret in my hosting environment variables had been truncated on copy-paste. It was missing its prefix. I replaced it, the provider's automatic retry hit the endpoint, and it returned <code>200 {"received": true}</code>. Plan activated.</p> <p>Two lessons:</p> <ol> <li> <strong>Test the payment chain with real money before launch.</strong> Otherwise your first customer pays and stays on the free plan, and you find out from an angry email.</li> <li> <strong>When signature verification fails, check the config before rewriting the code.</strong> Most of the time it's the boring cause.</li> </ol> <h2> The irony </h2> <p>The whole reason I built ApiPulse is silent failures.</p> <p>Most uptime tools check whether an endpoint returns 200. But a 200 OK can still carry an empty body, a malformed payload, or an error wrapped inside a "successful" response. The dashboard stays green while the thing is broken.</p> <p>ApiPulse lets you assert on what comes back:</p> <ul> <li>status code</li> <li>response body contains / doesn't contain a string</li> <li>response time under a threshold</li> <li>a header exists</li> </ul> <p>Plus SSL expiry alerts, public status pages, and alerts that fire only when status changes, not on every check.</p> <p>Stack: Angular (standalone components + signals), Node/Express + TypeScript, PostgreSQL, Resend for email, Paddle for payments.</p> <p>There's a free plan with 3 monitors: <a href="https://apipulse.live" rel="noopener noreferrer">https://apipulse.live</a></p> <h2> A question for you </h2> <p>If you run APIs in production: what failure has your monitoring missed? I built this from my own frustration, which is a sample size of one, so I'd like to know whether it matches yours.</p> webdev api node showdev