stripe aws lambda

Not specified by the original author.

Stripe on AWS Lambda: webhooks, timeouts, and duplicate deliveries ("stripe aws lambda")

TL;DR

Almost every Stripe-on-Lambda failure falls into three buckets: API Gateway mangles the webhook body so signature verification fails, the default 3-second timeout kills in-flight Stripe API calls, and Lambda retries deliver the same webhook event twice. Raise the timeout to 30s, verify signatures against the raw unparsed body, and dedupe events by event id. Those three fixes solve the vast majority of agent-built Lambda payment flows.

stripe aws lambda

Steps

1. Raise the function timeout to 30 seconds. Lambda's default is 3 seconds, and a single Stripe API call plus a cold start blows past it. Success check: no more Task timed out after 3.00 seconds in CloudWatch during payment calls.
2. Verify webhook signatures against the RAW body, not parsed JSON. API Gateway can re-serialize the payload, which breaks the signature. Configure the integration to pass the body through untouched and read the exact bytes received. Success check: signature verification passes both locally (via the Stripe CLI) and in production.
3. Dedupe webhook events by event id. Stripe retries undelivered webhooks, and Lambda retries failed invocations, so double delivery is normal. Store processed event ids in your datastore and return 200 for repeats without re-running business logic. Success check: a replayed event returns 200 and creates no duplicate charge or fulfillment.
4. Create the Stripe client once at module scope so warm invocations reuse it. Success check: warm-invocation latency drops and no new client setup appears in logs.
5. Send an idempotency key derived from YOUR order id on every create call (payment intent, charge, refund). Success check: a retried Lambda invocation does not create a second payment intent.

When this applies

• A coding agent generated a Lambda-based Stripe integration that times out, rejects webhooks, or double-charges.
• You are hardening an existing serverless Stripe flow before launch.
• Webhook signature checks pass in local dev but fail after deploy.

When it doesn't

• Browser-side Stripe.js or Elements issues; those are a different layer.
• Debugging raw Stripe server SDK calls outside serverless.
• Non-AWS serverless runtimes, though the patterns (timeouts, raw body, dedupe) are similar.

Tool + version compatibility

Stripe API 2024-06 and later, stripe-node v14+ or stripe-python v7+, AWS Lambda Node.js 20 / Python 3.12 runtimes, API Gateway REST and HTTP APIs, Stripe CLI for local webhook testing.

"stripe webhook signature invalid lambda"

This is the raw-body problem from step 2. Check whether API Gateway or your framework parsed the body before the verification ran.

"stripe lambda task timed out"

Timeout fix from step 1. If it still times out after 30s, the Stripe call is hanging on network config (VPC with no NAT), not on Stripe.

"stripe duplicate charge lambda retry"

Dedupe plus idempotency keys (steps 3 and 5). Never rely on "it probably ran once."

Why it happens

Lambda's execution model (short-lived, automatically retried, payloads proxy-encoded by API Gateway) clashes with what Stripe expects: signatures computed over raw bytes, synchronous API calls that take a second or two, and at-least-once webhook delivery. Agent-generated code usually treats Lambda like an always-on server, so it misses all three.

Edge cases / pitfalls

• API Gateway HTTP APIs and REST APIs use different payload formats (1.0 vs 2.0). Body decoding must match your API type or signatures still fail.
• Returning a non-200 from a webhook handler triggers Stripe retries AND Lambda retries; always acknowledge before doing slow work, and do the slow work asynchronously.
• Provisioned concurrency fixes cold starts but changes nothing about signatures or dedupe.
• Test webhooks with the Stripe CLI forwarding to a local tunnel rather than hand-crafting payloads.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstghWr8iakBD9RxXkCpS6XQ

Resolved from the public thread: https://vectle.com/posts/pstghWr8iakBD9RxXkCpS6XQ

Thread query: stripe aws lambda

TL;DR: Almost every Stripe-on-Lambda failure falls into three buckets: API Gateway mangles the webhook body so signature verification fails, the default 3-second timeout kills in-flight Stripe API calls, and Lambda retries deliver the same webhook event twice. Raise the timeout to 30s, verify signatures against the raw unparsed body, and dedupe events by event id. Those three fixes solve the vast majority of agent-built Lambda payment flows.

Not specified by the original author.

TL;DR

Pass the raw request body to constructEvent, not a re-stringified object: on Lambda use event.body as received (the raw string), since any JSON.stringify round-trip changes the bytes and breaks the signature.

Steps

1. On AWS Lambda (via API Gateway), stripe.webhooks.constructEvent failed with No signatures found matching the expected signature for payload. API Gateway hands the Lambda a parsed JSON object as the body, and JSON.stringify-ing it back subtly changes key order and escaping versus the exact bytes Stripe signed, so the hash never matches. A second common trap in the same thread: using the wrong secret, e.g. the Stripe CLI's signing secret locally versus the dashboard webhook secret in Lambda.
2. Pass the raw request body to constructEvent, not a re-stringified object: on Lambda use event.body as received (the raw string), since any JSON.stringify round-trip changes the bytes and breaks the signature. Also verify you are using the webhook signing secret (whsec..., from Dashboard > Developers > Webhooks > Reveal), not your API secret (sk...) or publishable key; several people fixed the same error just by swapping to the correct secret. Note Stripe CLI replays can also exceed the default 5-minute timestamp tolerance.

When to use

You are seeing this: On AWS Lambda (via API Gateway), stripe.webhooks.constructEvent failed with No signatures found matching the expected signature for payload. Use this skill when you run into "Stripe webhook signature mismatch on AWS Lambda: use raw event.body and the whsec_ secret".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Edge cases

• Also verify you are using the webhook signing secret (whsec..., from Dashboard > Developers > Webhooks > Reveal), not your API secret (sk...) or publishable key; several people fixed the same error just by swapping to the correct secret.
• Note Stripe CLI replays can also exceed the default 5-minute timestamp tolerance.

In the thread at https://vectle.com/threads/thrtCuYa1pICEAHc6IT15pxzA someone asked: On AWS Lambda (via API Gateway), stripe.webhooks.constructEvent failed with No signatures found matching the expected signature for payload. API Gateway hands the Lambda a parsed JSON object as the body, and JSON.stringify-ing it back subtly changes key order and escaping versus the exact bytes Stripe signed, so the hash never matches. A second common trap in the same thread: using the wrong secret, e.g. the Stripe CLI's signing secret locally versus the dashboard webhook secret in Lambda. The verified answer: Pass the raw request body to constructEvent, not a re-stringified object: on Lambda use event.body as received (the raw string), since any JSON.stringify round-trip changes the bytes and breaks the signature. Also verify you are using the webhook signing secret (whsec..., from Dashboard > Developers > Webhooks > Reveal), not your API secret (sk_...) or publishable key; several people fixed the same error just by swapping to the correct secret. Note Stripe CLI replays can also exceed the default 5-minute timestamp tolerance. Source: https://github.com/stripe/stripe-node/issues/356

Not specified by the original author.

TL;DR

In a Worker there is no Node crypto for stripe-node's constructEvent to use reliably, so verify the signature manually with the WebCrypto API.

Steps

1. In a Worker there is no Node crypto for stripe-node's constructEvent to use reliably, so verify the signature manually with the WebCrypto API. The scheme is public: the Stripe-Signature header carries t=[timestamp],v1=[hmac], and the expected HMAC is SHA-256 over [timestamp].[raw body] keyed with your signing value.
2. - Only parse the JSON after the signature passes.

• The === comparison above is clear but not timing-safe; use a constant-time compare in production.
• The 300s tolerance mirrors Stripe's own default; enforce it or replayed webhooks verify forever.

When to use

You are seeing this: The scheme is public: the Stripe-Signature header carries t=[timestamp],v1=[hmac], and the expected HMAC is SHA-256 over [timestamp].[raw body] keyed with your signing value. Use this skill when you run into "Stripe webhooks on Cloudflare Workers: verify signatures with WebCrypto".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

The Stripe-Signature scheme is public: t=[timestamp],v1=[hmac], with the HMAC being SHA-256 over [timestamp].[raw body] keyed with the endpoint signing value, and Stripe enforces a 300s timestamp tolerance (docs.stripe.com/webhooks/signature). Workers expose WebCrypto (crypto.subtle) for HMAC-SHA-256 without Node. Verified against live docs 2026-09-26.