Every genuinely valid Stripe webhook is rejected as an invalid signature

Nobody has started this yet — be first.

Business impact

Every subscription activation, plan change, cancellation, and payment-failure notice from Stripe arrives through this one endpoint. Right now, POST /webhooks/stripe rejects every genuinely valid Stripe-signed request as 400 invalid_signature, because the code verifies the signature against a re-serialized copy of the body instead of the exact bytes Stripe sent and signed. In practice: a customer pays, Stripe fires checkout.session.completed, the webhook 400s, Stripe retries on its own schedule and eventually gives up, and the tenant's subscription is never marked active -- the customer paid and still sees "upgrade required." Nothing about this fails loudly on our side, so the realistic way this gets noticed is a support ticket from a paying customer who cannot access what they paid for.

Problem

stripe_webhook verifies the Stripe signature against json.dumps(request.get_json()) instead of the untouched raw request bytes Stripe actually signed.

Current behavior

stripe_webhook parses the body with request.get_json(silent=True) first, then re-serializes the resulting dict with json.dumps(...) to build raw_body before calling verify_and_parse -- but Stripe's signature was computed over its own compact, minified JSON formatting, which json.dumps's default key order and whitespace do not reproduce, so verification fails for every real payload.

Expected behavior

POST /webhooks/stripe verifies the signature against request.get_data() -- the untouched raw bytes of the request body -- and only parses JSON after that verification succeeds.

Steps to reproduce

Build a validly-signed webhook payload the way Stripe actually formats one (compact separators, no extra whitespace), signed over the exact bytes.
POST those exact bytes with a correct Stripe-Signature header.
Observe: 400 invalid_signature, even though the signature is genuinely valid for the bytes sent.

Why this matters

This is the single most common real-world Stripe (or any HMAC-signed webhook) integration bug, and it is exactly why request.get_data() has to be the first thing touched in the handler, before any JSON parsing of any kind, even parsing that looks harmless. The fix is not "parse JSON differently" -- it is "verify against the bytes you actually received, and only parse afterward, from the same untouched bytes."

Suggested approach

Look at how stripe_webhook currently obtains raw_body, and compare it to app/billing/stripe_service.py's own docstring describing the rule. request.get_data() is available on the request object already imported into this file.

Acceptance criteria

A validly-signed webhook (signed over the real raw bytes) is accepted (200), regardless of JSON formatting/whitespace
A tampered payload or wrong secret is still correctly rejected (400) -- verification is not accidentally made a no-op
JSON parsing happens only after signature verification succeeds

Verification

pytest practice_tickets/tests/test_ticket_07_webhook_signature_raw_body.py -v

Hints (0/2)

Try it without hints first — the reading is the exercise.

Working on this ticket

Work on a branch named for the ticket — that's what you'll submit.

Branch off your fork

$git checkout -b fix/webhook-signature-raw-body

Fix it and commit

Meet every acceptance criterion, and add a test that would have caught this.

Push the branch

$git push -u origin fix/webhook-signature-raw-body

Submit it below

Paste your fork URL and the branch name, with a short write-up of the root cause.

Submit your fix

Questions

Stuck on something?

Ask about anything unclear in the ticket — the maintainer and anyone who has solved it can answer. Please don't post full solutions.

No questions yet. If something in this ticket reads ambiguously, you are probably not the only one — ask.

The project

Multi-Tenant SaaS Starter

A Flask multi-tenant SaaS reference app where Postgres Row-Level Security -- not an app-level `WHERE tenant_id = ...` -- is the actual isolation boundary, plus subdomain tenant resolution, per-tenant RBAC, an append-only audit trail, and idempotent Stripe subscription billing.

Fork on GitHub

Download

Setup

Multi-Tenant SaaS Starter

git clone <your-fork>
cd FlaskDevTraining/saas_starter
docker compose up --build   # Postgres + Redis + the Flask dev server (auto-reload)

Migrations (including the RLS policies) run automatically on boot. Then seed two demo tenants -- (active subscription) and (still on trial):