Skip to main content
In this guide, you’ll learn how a provider webhook becomes account and payout status changes. Mercur already wires this up. A subscriber listens for payout.webhook_received and drives the update workflow. Understanding the path lets you emit the event yourself or extend the flow.

The built-in path

The payout-webhook subscriber resolves the raw payload to an action through the provider, then runs processPayoutForWebhookWorkflow:
src/subscribers/payout-webhook.ts (shipped)
getWebhookActionAndData delegates to the provider, which parses its own payload and returns a PayoutWebhookResult. The result is an action plus the affected id.

Run the workflow directly

To process an already-parsed result yourself, run the workflow with a PayoutWebhookResult:
The workflow branches on action, updating the account or the payout:
Actions the provider can’t map return not_supported (or a missing data.id), and the workflow makes no change. It is safe to hand it every event the provider sends.

Emit the event yourself

To route a custom provider integration through the same path, emit payout.webhook_received with the raw payload and let the shipped subscriber take over.