A PayPal payment goes through several events
A PayPal checkout rarely jumps straight from "created" to "paid" in a single notification. Depending on the payment method (account balance, card, international boleto), your integration may receive PAYMENT.SALE.PENDING first, and only later PAYMENT.SALE.COMPLETED — or PAYMENT.SALE.DENIED if the payment is declined during processing. Testing only the success event leaves that intermediate flow uncovered.
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\":\"WH-1\",\"event_type\":\"PAYMENT.SALE.PENDING\",\"resource\":{\"id\":\"8XY123\",\"state\":\"pending\",\"amount\":{\"total\":\"49.90\",\"currency\":\"USD\"}}}" },
{ "status": 200, "body": "{\"id\":\"WH-2\",\"event_type\":\"PAYMENT.SALE.COMPLETED\",\"resource\":{\"id\":\"8XY123\",\"state\":\"completed\",\"amount\":{\"total\":\"49.90\",\"currency\":\"USD\"}}}" }
]What about webhook signature verification?
Real limitation, no sugarcoating: PayPal doesn't use a simple HMAC — official verification calls PayPal's own
/v1/notifications/verify-webhook-signature API with the paypal-transmission-id/paypal-transmission-sig/paypal-cert-url headers received. httpdrop's template engine doesn't reproduce that verification flow (no signature helper exists). What it tests well is the logic that reacts to each event_type — verification still needs to be tested separately, with a real webhook or PayPal's developer dashboard Webhooks Simulator.Next step: see the PayPal REST endpoints to complete the checkout flow, not just the webhook.