Webhook Monitoring for Fintech and Payments
A dispute notification you never processed becomes an automatic loss. The response window is measured in days and set by your processor.
In payments, a missed webhook is not a delayed record. It is money in a state nobody is tracking, and several of those states have deadlines attached that expire whether you knew about them or not.
Disputes are the clearest example
Cardholders generally have 120 days from the transaction or expected delivery date to file a dispute. Your window to respond is far shorter and is set by your processor rather than the card network: Stripe and Shopify Payments both document a response window of roughly 7 to 21 days per dispute.
Missing that deadline loses the case automatically, with no appeal, regardless of how strong your evidence was. If the dispute notification arrived as a webhook your system silently dropped, the first you hear of it is the debit on your statement.
This is the cleanest argument for webhook monitoring anywhere in this industry. The cost of the miss is not the engineering time to fix it. It is the transaction amount plus the fee, and it is unrecoverable.
Money states that disagree
Authorisation, capture and settlement are separate events, and an integration that misses one leaves a record that is internally consistent and wrong.
| Missed event | Resulting state | Who notices, and when |
|---|---|---|
| payment_intent.succeeded | Customer charged, no order exists | The customer, within hours |
| charge.dispute.created | Response window expires unused | Nobody, until the funds are gone |
| charge.refunded | Ledger overstates revenue | Finance, at month end |
| payout.failed | Funds never reached your bank | Treasury, eventually |
| payment_intent.payment_failed | Dunning never starts | Churn, silently |
The second row is the only one where nothing in your normal operations surfaces the problem. Every other row has a human who complains.
Reconciliation is a control, not a report
In most industries, comparing your records against the provider's is good hygiene. In payments it is the thing that catches what monitoring cannot, and it should run daily rather than at month end.
Treat any non-empty output as an incident rather than a discrepancy to look at later. A single unmatched charge is usually a symptom of a handler that has been dropping a class of event for some time.
Idempotency is a financial requirement here
Webhook delivery is at-least-once, and a timeout after your handler committed produces a retry of work already done. In most applications that creates a duplicate row. In payments it can create a duplicate refund or a duplicate payout.
Store the provider's event ID with a unique constraint and let the database reject the second attempt. Application-level checks race under concurrency; a unique index does not.
What to monitor, in priority order
Dispute and chargeback events first, because they have hard deadlines. Then payment success events, because those represent customers waiting for something. Then refunds and payouts, which cause accounting problems rather than customer problems. Then everything else.
SensaCat tracks multi-step payment flows per transaction, so an authorisation that never became an order is flagged against that specific payment rather than averaged into a throughput graph. Start free.
The mechanics are covered in business flow monitoring.