Skip to main content
Use a Stripe webhook endpoint to send the payment events someone has to act on to Flashduty On-call:
  • Disputes and inquiries (charge.dispute.*): an alert opens when a cardholder disputes a charge or the issuer sends an inquiry, and recovers when Stripe closes the case (won, lost, or inquiry closed)
  • Failed payouts (payout.failed): an alert opens when a payout to a bank account or debit card fails
  • Early fraud warnings (radar.early_fraud_warning.*): an alert opens when a card issuer reports a payment as possibly fraudulent, and recovers once the payment is disputed or fully refunded
Every Stripe account can create webhook endpoints, up to 16 per account.

In Flashduty On-call

You can get the integration push URL in either of the following ways.

Use a dedicated integration

  1. In the Flashduty console, go to Channels and open a channel
  2. Select Configuration → Integrations → Private integration, then click Add integration
  3. Select Stripe and click Save
  4. Open the generated integration card and copy the Push URL

Use a shared integration

  1. In the Flashduty console, go to Integration Center → Alert Events
  2. Select Stripe and enter an integration name
  3. Configure the default route and select a channel. You can add more rules under Routing after creation
  4. Click Save and copy the generated Push URL

Configure Stripe

1

Create an event destination in Stripe

Where: Stripe Dashboard › Workbench › Webhooks › Create an event destinationYou need a Stripe role that can manage webhooks, such as Administrator or Developer.
2

Select events

Where: Stripe Dashboard › Workbench › WebhooksSelect the following events:If the destination subscribes to other event types (for example charge.succeeded), Flashduty returns success and creates no alert. We recommend subscribing only to the events above.
3

Enter the push URL

Where: Stripe Dashboard › Workbench › Webhooks › Create an event destination › Continue › Webhook endpointClick Create destination. Flashduty does not use the signing secret (starting with whsec_) shown on the endpoint page, so you do not need to copy it.Webhook endpoints in test environments (sandbox or test mode) and in live mode are separate. To connect both, create an endpoint in each environment; they can use the same push URL.
4

Turn on the auto-resolve timeout

Where: Flashduty console › Channels › Configuration › Settings › Advanced SettingsFailed payouts have no recovery event, and an early fraud warning that is never disputed or refunded is not followed by another event. Closing the incident also closes its alerts. See auto-resolve timeout.A dispute usually takes 2 to 3 months from creation to closure, and the auto-resolve timeout also closes incidents for disputes that are still open. To keep dispute alerts open until Stripe closes the dispute, use a shared integration and route alerts whose object label is dispute to a channel without the auto-resolve timeout.
5

Verify

Where: Stripe Dashboard › Workbench › WebhooksThe Send test events button on the destination page only shows Stripe CLI instructions and sends nothing. Create real test events in a test environment in any of these ways:
  • Run stripe trigger charge.dispute.created with the Stripe CLI
  • Pay with test card 4000000000000259: the payment succeeds and is then disputed as fraudulent. Pay with 4000000000005423 to receive an early fraud warning
  • Submit winning_evidence (or losing_evidence) as the dispute evidence: the dispute closes as won (or lost) and Flashduty recovers the alert. Fully refund the early-fraud-warning payment: Stripe sends radar.early_fraud_warning.updated with actionable set to false and Flashduty recovers the alert
  • payout.failed needs a failed payout. A sandbox does not accept test bank accounts in its own payout settings; on a Connect platform, pay out from a test connected account whose bank account uses account number 000111111116, with a destination that receives Connected accounts events
Test events have livemode set to false. Flashduty creates alerts for them as usual and adds the label livemode=false.After a few seconds, go back to Flashduty. If the integration shows a Latest event time, the setup works.

Payload

Stripe sends one event (an Event object) per request, with the affected object in data.object: Every alert also carries the label source=stripe. Example titles: Stripe dispute needs response: fraudulent, Stripe inquiry under review: general, Stripe payout failed: account_closed, Stripe early fraud warning: made_with_stolen_card.

Alert key

Flashduty uses data.object.id (the ID of the dispute, payout, or warning itself) as the Alert Key, not the event ID:
  • The created, funds_withdrawn, updated, and closed events for one dispute land on the same alert, which recovers when the dispute closes
  • The created and updated events for one early fraud warning land on the same alert
  • A dispute and an early fraud warning on the same payment are two alerts
  • Stripe retries failed deliveries (for up to 3 days in live mode) and occasionally sends two events for one change; these events merge into the original alert instead of creating duplicates

Status and severity

A request is rejected if an event that creates an alert has no data.object.id.

FAQ

Some disputes cannot be challenged (for example, disputes on the Cartes Bancaires network), and Stripe closes them as lost at the time it notifies you. There is nothing to act on, so Flashduty treats the event as a recovery and does not open an alert. These disputes still appear in the disputes list in the Stripe Dashboard.
Create the endpoint in live mode only. According to the Stripe documentation, a Connect platform’s live-mode endpoint for Connected accounts also receives test events from connected accounts. Those alerts carry the label livemode=false, and you can route them to another channel by that label in a shared integration.
No. Flashduty identifies the integration by the integration_key in the push URL and does not verify the Stripe-Signature header. Keep the push URL as secret as a key.

Troubleshooting

  • Stripe shows failed deliveries (4xx): make sure the push URL is complete (it includes integration_key) and the event payload style is Snapshot
  • Deliveries succeed but no alert appears: make sure the event type is in the table above; other event types create no alert
  • The alert does not recover after the dispute closes: make sure the endpoint subscribes to charge.dispute.closed
  • Check delivery history: in Workbench, select the endpoint under Webhooks and open the Event deliveries tab to see each delivery’s status code and resend events