Skip to main content
Webhooks allow your application to receive real-time notifications when events occur in your Paygentic account. When enabled, we’ll send HTTP POST requests to your configured endpoints whenever relevant events happen, such as customer creation, subscription changes, and more.

Quickstart guide

Get up and running with webhooks in just a few minutes:
1

Enable webhooks

Navigate to the Developer > Webhooks section in your Paygentic dashboard and toggle webhooks on.
2

Configure your endpoint

Once enabled, select “Manage Webhook Endpoints” to access the webhook management portal where you can:
  • Add your webhook endpoint URL (e.g., https://your-domain.com/webhooks/paygentic)
  • Select which event types to subscribe to
  • View your webhook signing secret
3

Test your endpoint

Use tools like Hookdeck or ngrok to test webhooks during development without deploying to production.
4

Verify and process events

Setting up webhooks

Enabling webhooks

  1. Access the dashboard: Log in to your Paygentic account and navigate to Developer > Webhooks
  2. Enable webhooks: Toggle the “Enable Webhooks” switch to activate webhook functionality
  3. Access management portal: Select “Manage Webhook Endpoints” to open the webhook management portal

Configuring endpoints

In the webhook management portal, you can:
  • Add endpoints: Specify the URL where you want to receive webhook events
  • Select event types: Select which events you want to subscribe to
  • Set filters: Configure advanced filtering rules if needed
  • View logs: Monitor webhook deliveries and debug any issues
  • Retrieve signing secret: Access your webhook signing secret for verification
Remember to keep your webhook signing secret secure and never commit it to version control. Store it in environment variables or a secure secrets management system.

Best practices

  • Use HTTPS endpoints only (HTTP is not supported for security reasons)
  • Implement webhook processing asynchronously to respond quickly
  • Store the svix-id to handle duplicate events (idempotency)
  • Disable CSRF protection for your webhook endpoint
  • Respond with a 2xx status code within 15 seconds

Security and verification

Webhook security is critical to ensure that the events you receive are legitimate and have not been tampered with. Paygentic signs all webhooks with HMAC-SHA256.

Required headers

Every webhook request includes three important headers:
  • svix-id: Unique identifier for the webhook message (use for idempotency)
  • svix-timestamp: Unix timestamp when the webhook was sent
  • svix-signature: Base64 encoded signature(s) for verification

Signature verification

Always verify webhook signatures in production. This prevents attackers from sending fake events to your endpoint.
Use Svix’s verification library for easy and secure webhook verification:

Verification examples

Replay attack protection

The timestamp in the svix-timestamp header protects against replay attacks. The Svix library automatically rejects webhooks with timestamps more than 5 minutes old (past or future). Ensure your server’s clock is synchronized using NTP.

Handling webhooks

Response requirements

  • Status code: Return a 2xx status code (200-299) to indicate successful receipt
  • Timeout: Respond within 15 seconds or the delivery will be considered failed
  • Body: The response body is ignored - a simple “OK” or empty response is fine

Processing best practices

Idempotency

Use the svix-id header to ensure you only process each event once:

CSRF protection

Disable CSRF protection for webhook endpoints. Webhooks are verified using signatures, not CSRF tokens.

Retry policy and failure handling

Automatic retry schedule

If your endpoint fails to respond successfully, we will retry with exponential backoff:

Failure scenarios

A webhook delivery is considered failed if:
  • Your endpoint returns a non-2xx status code
  • Your endpoint does not respond within 15 seconds
  • The endpoint is unreachable (connection error)
  • Your endpoint returns a 3xx redirect (not followed)

Endpoint disabling

If an endpoint fails continuously for 5 days, it will be automatically disabled. You’ll receive an operational webhook notification when this happens. You can re-enable the endpoint from the webhook management portal.

Manual recovery

You can manually retry failed webhooks through the webhook management portal:
  • Individual retry: Retry a specific failed message
  • Bulk recovery: Replay all failed messages from a specific date
  • View logs: Inspect delivery attempts and error messages

Event types reference

Paygentic currently supports the following webhook event types:
Triggered when a new customer is successfully created.
Triggered when customer creation fails.
Triggered when a new subscription is created.
Triggered when a subscription becomes active and ready for use.This event fires when a subscription transitions to the active state, which happens either:
  • Immediately upon creation for subscriptions without upfront costs
  • After successful payment of upfront costs for subscriptions requiring wallet prefunding
Key distinction: While subscription.created.v0 fires when a subscription is first created (which may be in pending_payment state), subscription.activated.v0 fires when the subscription is ready for use. Use this event to provision access or activate features for customers.
Best practice: Listen to subscription.activated.v0 for production-readiness signals and service provisioning, rather than subscription.created.v0, to ensure the subscription has been fully funded and is ready for use.
Triggered when a subscription is cancelled.
Triggered when a subscription is updated (e.g., plan change, quantity adjustment).
Triggered when a payment is successfully completed.
Triggered when a payment attempt fails. Includes error details from the payment processor.
Triggered when a payment session expires before the customer completes it.
Triggered when an invoice is issued and a payment session is opened.
Triggered when an invoice transitions to PAID — covers subscription renewals, grant purchases (the grantId is included in the payload), out-of-band payments, and zero-amount invoices.
grantId is populated only when the invoice was created via POST /v1/entitlements/{id}/grants/purchase; otherwise it is omitted. paymentIntentId is present for Stripe-routed payments and omitted for out-of-band and zero-amount invoices.
grandTotal is the authoritative amount paid. subtotal and totalTax are each rounded to 2 decimal places independently, so re-adding them can land a cent off grandTotal — use grandTotal directly rather than re-summing the parts.
This event is delivered at least once. On rare retries you may receive the same invoice.paid.v0 more than once for a given invoice — dedupe on invoiceId (or the Svix message idempotency key) before acting on it.
Triggered when a usage source is successfully activated and connected.
Triggered when a usage source fails to activate due to configuration or authentication issues.
Triggered when a usage source is disconnected or deactivated.
Triggered when a source event enters pending state and requires manual processing.
Triggered when a source event is successfully processed into usage events.
Triggered when a source event fails to process due to errors.
Triggered when a source event is manually rejected by a user.

Common event fields

All webhook events include these standard fields:

Code examples

Complete webhook handler

Here’s a production-ready webhook handler example:

Testing webhooks locally

For local development, use a tunneling service to expose your local server:
Then add this URL as your webhook endpoint in the webhook management portal for testing.

Additional resources

Need help?

If you encounter any issues with webhooks:
  1. Check the delivery logs in the webhook management portal for error messages
  2. Verify your endpoint is returning a 2xx status code
  3. Ensure you’re using the correct signing secret
  4. Confirm your server’s clock is synchronized (for timestamp validation)
  5. Contact support if you need additional assistance