PayPal Webhooks: Send Payment Events to Sazabi

Webhook facts checked on the platform’s docs on Nov 8, 2026.

PayPal calls your listener URL when a payment, order, dispute or subscription changes state. If that URL is a Sazabi intake URL, each notification becomes a log record you can search later, even if your own code never handled it.

What PayPal sends

PayPal webhooks are HTTPS posts that carry a JSON event. The event types are listed by name in the event names reference, for example:

• PAYMENT.CAPTURE.COMPLETED, PAYMENT.CAPTURE.DENIED and PAYMENT.CAPTURE.REFUNDED for captures
• CHECKOUT.ORDER.APPROVED when a buyer approves an order
• CUSTOMER.DISPUTE.CREATED when a dispute opens
• BILLING.SUBSCRIPTION.ACTIVATED for subscriptions

The body is the event itself. It includes an event id, event_version, create_time, resource_type, event_type, a human-readable summary and a resource object with the details of the capture, order or dispute.

Why send PayPal webhooks to Sazabi

Payment webhooks are the system of record for what happened after the buyer left your checkout. When a customer says they paid and your order is still pending, you want to know whether PayPal sent the event and whether your handler saw it.

Sazabi's Webhook Events source stores each JSON payload as a log record, with the payload under webhook.* attributes, so you can search by order ID or capture ID. Your application logs and PayPal's own event history then answer the question together. A suffix such as /paypal on the intake URL is stored as webhook.path.

Set up PayPal webhooks

Copy the intake URL from your Webhook Events source and keep it secret, since it encodes your project key. In PayPal:

1. Open Application management in the PayPal developer dashboard and select the app.
2. Add a webhook and paste the intake URL as the listener URL.
3. Pick the event types to deliver. Choosing only the ones you need keeps your record count down.
4. Save the subscription and note the Webhook ID PayPal assigns.

You can do the same through the Webhooks Management API. PayPal states that the listener must be on HTTPS port 443, so paste the intake URL exactly as Sazabi shows it and check the scheme and port match.

To test, use the Webhooks simulator. It creates mock events that belong to no app, so you can confirm a record appears in Sazabi without making a payment. For real test events, subscribe the URL to a sandbox app and run a sandbox payment.

Example PayPal payload

This abbreviated example is based on the PAYMENT.CAPTURE.COMPLETED sample in the PayPal docs. The values are illustrative.

{
  "id": "WH-3F562076HD293871E-75F399086E414290U",
  "event_version": "1.0",
  "create_time": "2024-05-16T05:19:19.355Z",
  "resource_type": "capture",
  "resource_version": "2.0",
  "event_type": "PAYMENT.CAPTURE.COMPLETED",
  "summary": "Payment completed for $ 500.0 USD",
  "resource": {
    "id": "3Y662965014333303",
    "status": "COMPLETED",
    "amount": { "value": "500.00", "currency_code": "USD" },
    "final_capture": true
  }
}

Once stored, a search on a top-level field such as event_type works the same way as the webhook.event example in the Sazabi docs.

What to watch for

• Missing 2xx responses. If PayPal gets no response, cannot connect or sees a 404 or 500, it retries each delivery up to 25 times over 3 days. A long run of retries means the listener has a problem.
• Blocked connections. PayPal says the usual cause of no status code is a firewall blocking HTTPS on port 443 or a domain flagged by URL filtering services.
• Duplicate or late events. Retries mean the same event can arrive more than once. Use the event id to tell copies apart.
• Event gaps. Compare PAYMENT.CAPTURE.COMPLETED counts with your own order logs by day.
• Signing. PayPal signs each message, and its docs show how to verify it with the webhook ID, a certificate and a CRC32 of the body.

Related guides cover Square and QuickBooks webhooks. See the integrations list or pricing for what else you can connect.