One payload doesn't test the whole flow
Testing with a single payment_intent.succeeded event validates your handler parses that shape — but doesn't test whether your system correctly handles the sequence of events a real payment fires: creation, processing, and only then success (or failure). See the Stripe endpoint and payload reference if you just need a static example.
Modeling the lifecycle with Response Sequences
Configure a Mock Rule with Response Sequences so each call to your receiving endpoint returns the next event in the sequence:
// Mock Rule: POST / → Response Sequences, mode: last
[
{ "status": 200, "body": "{\"id\":\"evt_1\",\"type\":\"payment_intent.created\",\"data\":{\"object\":{\"id\":\"pi_1\",\"status\":\"requires_payment_method\"}}}" },
{ "status": 200, "body": "{\"id\":\"evt_2\",\"type\":\"payment_intent.processing\",\"data\":{\"object\":{\"id\":\"pi_1\",\"status\":\"processing\"}}}" },
{ "status": 200, "body": "{\"id\":\"evt_3\",\"type\":\"payment_intent.succeeded\",\"data\":{\"object\":{\"id\":\"pi_1\",\"status\":\"succeeded\"}}}" }
]What about the stripe-signature header?
Real limitation, no sugarcoating: httpdrop's template engine has no HMAC/signature helper — it cannot generate a cryptographically valid
stripe-signature header from the mock. Signature verification in your webhook handler needs to be tested separately (bypassed via a test-environment flag, or tested with a test payload+secret generated by Stripe's own library). httpdrop simulates the payload and event sequence, not delivery cryptography.Next step: see the Stripe REST endpoints (Payment Intents) to complete the checkout flow, not just the webhook.