Use incoming webhooks to get real-time updates

Why to use webhooks

When building Stripe integrations, you might want your applications to receive events as they occur in your Stripe accounts, so that your backend systems can execute actions accordingly.

To enable webhook events, you need to register webhook endpoints. After you register them, Stripe can push real-time event data to your application’s webhook endpoint when events happen in your Stripe account. Stripe uses HTTPS to send webhook events to your app as a JSON payload that includes an Event object.

Receiving webhook events are particularly useful for listening to asynchronous events such as when a customer’s bank confirms a payment, a customer disputes a charge, a recurring payment succeeds, or when collecting subscription payments.

Event overview

Stripe generates event data that we can send you to inform you of activity in your account.

When an event occurs, Stripe generates a new Event object. A single API request might result in the creation of multiple events. For example, if you create a new subscription for a customer, you receive customer.subscription.created and payment_intent.succeeded events.

By registering webhook endpoints in your Stripe account, you enable Stripe to automatically send Event objects as part of POST requests to the registered webhook endpoint hosted by your application. After your webhook endpoint receives the Event, your app can run backend actions (for example, calling your shipping provider’s APIs to schedule a shipment after you receive a payment_intent.succeded event).

Event object

The Event object we send to your webhook endpoint provides a snapshot of the object that changed. They might include a previous_attributes property that indicates the change, when applicable.

See the full list of event types that we send to your webhook.

Example event payload

The following event shows a subscription update at the end of a trial.

{
  "id": "evt_1MqqbKLt4dXK03v5qaIbiNCC",
  "object": "event",
  "api_version": "2023-08-16",
  "created": 1680064028,

Event object structure

Review the event object structure to better understand events and the underlying information they provide.

Event type

You receive events for all of the event types your webhook endpoint is listening for in your configuration. Use the received event type to determine what processing your application needs to perform. The data.object correspoding to each event type varies.

Livemode

You might receive both live and test mode event delivery requests to your endpoints. This can happen if you use a single endpoint for both live and test mode or if you’re a Connect platform making test mode requests for live Standard connected accounts. Use the livemode attribute to check whether the object exists in live or test mode, and determine the correct handling for the event.

API version

The api_version indicates the API version of the event and dictates the structure of the included data.object. Your endpoint receives events using the configured API version, which can differ from your account’s default API version or the API version of any requests related to the event. This attribute is determined by the destination endpoint, which indicates that the same event might be delivered to multiple endpoints using different API versions. If you use our Java, .NET or Go client libraries, make sure that you configure the endpoint API version to use the same API version pinned in the client. Otherwise, you might be unable to de-serialize the event objects.

When retrieving Event objects from the API, you can’t control the API version of the data.object structure. Instead, retrieve that object from the appropriate API endpoint and use the Stripe-Version header to specify an API version.

API request events

When an event is generated as a result of an API request, that request shows up as the request.id. If you use an idempotency_key when making the request, it’s included as the request.idempotency_key. Check this request hash when you investigate what causes an event.

Data object and previous attributes

For *.updated events, the event payload includes data.previous_attributes that allow you to inspect what’s changed about the Stripe object. The previous_ attributes in the example customer.subscription.updated event above indicates that the subscription has a previous value of status: trialing, among other changes. The data.object indicates the status as active which indicates that the subscription transitioned out of a trial period.

Pending deliveries

Use pending_webhooks to determine how many endpoints configured for this event haven’t responded successfully to delivery. During initial delivery, this value is 1 or higher because your endpoint hasn’t responded successfully. If you retrieve this event later, pending_webhooks decrease to a minimum of 0 as each endpoint responds successfully. This is important for invoice.created events because unsuccessful deliveries can delay invoice finalization.

Connected account events

Events from connected accounts delivered to a Connect endpoint include the account. Use account to track which connected account the object belongs to to make sure that your platform can process the event data appropriately.

Why event objects get generated

This table describes different scenarios that trigger generating Event objects.

How to set up your webhook integration

To start receiving webhook events in your app, create and register a webhook endpoint by following the steps below. You can register and create one endpoint to handle several different event types at once, or set up individual endpoints for specific events.

1. Identify which events you want to monitor.
2. Develop a webhook endpoint function to receive event data POST requests.
3. Test your webhook endpoint function locally using the Stripe CLI.
4. Register your endpoint within Stripe using the Webhooks Dashboard or the API.
5. Secure your webhook endpoint.

stripe help trigger

require 'json'

# Using Sinatra
post '/webhook' do
  payload = request.body.read
  event = nil

  begin
    event = Stripe::Event.construct_from(
      JSON.parse(payload, symbolize_names: true)
    )
  rescue JSON::ParserError => e
    # Invalid payload
    status 400
    return
  end

  # Handle the event
  case event.type
  when 'payment_intent.succeeded'
    payment_intent = event.data.object # contains a Stripe::PaymentIntent
    # Then define and call a method to handle the successful payment intent.
    # handle_payment_intent_succeeded(payment_intent)
  when 'payment_method.attached'
    payment_method = event.data.object # contains a Stripe::PaymentMethod
    # Then define and call a method to handle the successful attachment of a PaymentMethod.
    # handle_payment_method_attached(payment_method)
  # ... handle other event types
  else
    puts "Unhandled event type: #{event.type}"
  end

  status 200
end

stripe listen --forward-to localhost:4242/stripe_webhooks

stripe listen --events payment_intent.created,customer.created,payment_intent.succeeded,checkout.session.completed,payment_intent.payment_failed \
  --forward-to localhost:4242/webhook

stripe listen --load-from-webhooks-api --forward-to localhost:5000

Ready! Your webhook signing secret is '{{WEBHOOK_SIGNING_SECRET}}' (^C to quit)

stripe trigger payment_intent.succeeded
Running fixture for: payment_intent
Trigger succeeded! Check dashboard for event details.

https://<your-website>/<your-webhook-endpoint>

curl https://api.stripe.com/v1/webhook_endpoints \
  -u 
sk_test_4eC39HqLyjWDarjtT1zdp7dc
: \
  -d "url"="https://example.com/my/webhook/endpoint" \
  -d "enabled_events[]"="payment_intent.payment_failed" \
  -d "enabled_events[]"="payment_intent.succeeded"

Debugging webhook integrations

Multiple types of issues can occur when delivering events to your webhook endpoint:

• Stripe might not be able to deliver an event to your webhook endpoint.
• Your webhook endpoint might have an SSL issue.
• Your network connectivity is intermittent.
• Your webhook endpoint isn’t receiving events that you expect to receive.

View event deliveries

To view event deliveries for a specific endpoint, select the webhook endpoint in the Webhooks tab.

To view all events that were triggered in your account, view the Events tab.

Fix HTTP status codes

When an event displays a status code of 200, it indicates successful delivery to the webhook endpoint. You might also receive a status code other than 200. View the table below for a list of common HTTP status codes and recommended solutions.

Event delivery behaviors

This section helps you understand different behaviors to expect regarding how Stripe sends events to your webhook endpoint.

Explicitly, this section includes documentation on event retry deliveries, disabled endpoint deliveries, event versioning, and event ordering.

Retry behavior

In live mode, Stripe attempts to deliver a given event to your webhook endpoint for up to 3 days with an exponential back off. In the Events section of the Dashboard, you can view when the next retry will occur.

In test mode, Stripe retries three times over a few hours. You can manually retry transmitting individual events to your webhook endpoint after this time using the Events section of the Dashboard. You can also query for missed events to reconcile the data over any time period.

The automatic retries still continue, even if you manually retry transmitting individual webhook events to a given endpoint and the attempt is successful.

If your endpoint has been disabled or deleted when Stripe attempts a retry, future retries of that event are prevented. However, if you disable and then re-enable a webhook endpoint before Stripe can retry, you can still expect to see future retry attempts.

Disable behavior

In live and test mode, Stripe attempts to notify you of a misconfigured endpoint by email if the endpoint hasn’t responded with a 2xx HTTP status code for multiple days in a row. The email also states when the endpoint will be automatically disabled.

API versioning

The API version in your account settings when the event occurs dictates the API version, and therefore the structure of an Event object sent in a webhook. For example, if your account is set to an older API version, such as 2015-02-16, and you change the API version for a specific request with versioning, the Event object generated and sent to your endpoint is still based on the 2015-02-16 API version.

You can’t change Event objects after creation. For example, if you update a charge, the original charge event remains unchanged. This means that subsequent updates to your account’s API version don’t retroactively alter existing Event objects. Fetching older events by calling /v1/events using a newer API version also has no impact on the structure of the received events.

You can set test webhook endpoints to either your default API version or the latest API version. The Event sent to the webhook URL is structured for the endpoint’s specified version. You can also programmatically create endpoints with a specific api_version.

Event ordering

Stripe doesn’t guarantee delivery of events in the order in which they’re generated. For example, creating a subscription might generate the following events:

• customer.subscription.created
• invoice.created
• invoice.paid
• charge.created (if there’s a charge)

Your endpoint shouldn’t expect delivery of these events in this order, and needs to handle delivery accordingly. You can also use the API to fetch any missing objects (for example, you can fetch the invoice, charge, and subscription objects using the information from invoice.paid if you happen to receive this event first).

Best practices for using webhooks

Review these best practices to make sure your webhooks remain secure and function well with your integration.

Handle duplicate events

Webhook endpoints might occasionally receive the same event more than once. You can guard against duplicated event receipts by making your event processing idempotent. One way of doing this is logging the events you’ve processed, and then not processing already-logged events.

Only listen to event types your integration requires

Configure your webhook endpoints to receive only the types of events required by your integration. Listening for extra events (or all events) puts undue strain on your server and we don’t recommend it.

You can change the events that a webhook endpoint receives in the Dashboard or with the API.

Exempt webhook route from CSRF protection

If you’re using Rails, Django, or another web framework, your site might automatically check that every POST request contains a CSRF token. This is an important security feature that helps protect you and your users from cross-site request forgery attempts. However, this security measure might also prevent your site from processing legitimate events. If so, you might need to exempt the webhooks route from CSRF protection.

class StripeController < ApplicationController
  # If your controller accepts requests other than Stripe webhooks,
  # you'll probably want to use `protect_from_forgery` to add CSRF
  # protection for your application. But don't forget to exempt
  # your webhook route!
  protect_from_forgery except: :webhook

  def webhook
    # Process webhook data in `params`
  end
end

Receive events with an HTTPS server

If you use an HTTPS URL for your webhook endpoint, Stripe validates that the connection to your server is secure before sending your webhook data. For this to work, your server must be correctly configured to support HTTPS with a valid server certificate. Live mode requires HTTPS URLs. Stripe webhooks don’t currently support TLS v1.3.

Roll endpoint signing secrets periodically

The secret used for verifying that events come from Stripe is modifiable in the Webhooks section of the Dashboard. For each endpoint, click Roll secret. You can choose to immediately expire the current secret or delay its expiration for up to 24 hours to allow yourself time to update the verification code on your server. During this time, multiple secrets are active for the endpoint. Stripe generates one signature per secret until expiration. To keep them safe, we recommend that you roll secrets periodically, or when you suspect a compromised secret.

Verify events are sent from Stripe

Stripe sends webhook events from a set list of IP addresses. Only trust events coming from these IP addresses.

Additionally, verify webhook signatures to confirm that received events are sent from Stripe. Stripe signs webhook events it sends to your endpoints by including a signature in each event’s Stripe-Signature header. This allows you to verify that the events were sent by Stripe, not by a third party. You can verify signatures either using our official libraries, or verify manually using your own solution.

The following section describes how to verify webhook signatures:

1. Retrieve your endpoint’s secret.
2. Verify the signature.

Retrieving your endpoint’s secret

Use the Webhooks section of the Dashboard. Select an endpoint that you want to obtain the secret for, and find the secret on the top right of the page.

Stripe generates a unique secret key for each endpoint. If you use the same endpoint for both test and live API keys, the secret is different for each one. Additionally, if you use multiple endpoints, you must obtain a secret for each one you want to verify signatures on, and Stripe starts to sign each webhook it sends to the endpoint.

Verifying signatures using our official libraries

Use one of our official libraries to verify signatures; we recommend this approach to verify signatures. You perform the verification by providing the event payload, the Stripe-Signature header, and the endpoint’s secret. If verification fails, you get an error.

# Set your secret key. Remember to switch to your live secret key in production.
# See your keys here: https://dashboard.stripe.com/apikeys
Stripe.api_key = 
'sk_test_4eC39HqLyjWDarjtT1zdp7dc'

require 'stripe'
require 'sinatra'

# If you are testing your webhook locally with the Stripe CLI you
# can find the endpoint's secret by running `stripe listen`
# Otherwise, find your endpoint's secret in your webhook settings in
# the Developer Dashboard
endpoint_secret = 'whsec_...'

# Using the Sinatra framework
set :port, 4242

post '/my/webhook/url' do
  payload = request.body.read
  sig_header = request.env['HTTP_STRIPE_SIGNATURE']
  event = nil

  begin
    event = Stripe::Webhook.construct_event(
      payload, sig_header, endpoint_secret
    )
  rescue JSON::ParserError => e
    # Invalid payload
    puts "Error parsing payload: #{e.message}"
    status 400
    return
  rescue Stripe::SignatureVerificationError => e
    # Invalid signature
    puts "Error verifying webhook signature: #{e.message}"
    status 400
    return
  end

  # Handle the event
  case event.type
  when 'payment_intent.succeeded'
    payment_intent = event.data.object # contains a Stripe::PaymentIntent
    puts 'PaymentIntent was successful!'
  when 'payment_method.attached'
    payment_method = event.data.object # contains a Stripe::PaymentMethod
    puts 'PaymentMethod was attached to a Customer!'
  # ... handle other event types
  else
    puts "Unhandled event type: #{event.type}"
  end

  status 200
end

Preventing replay attacks

A replay attack is when an attacker intercepts a valid payload and its signature, then re-transmits them. To mitigate such attacks, Stripe includes a timestamp in the Stripe-Signature header. Because this timestamp is part of the signed payload, it’s also verified by the signature, so an attacker can’t change the timestamp without invalidating the signature. If the signature is valid but the timestamp is too old, you can have your application reject the payload.

Our libraries have a default tolerance of 5 minutes between the timestamp and the current time. You can change this tolerance by providing an additional parameter when verifying signatures. Use Network Time Protocol (NTP) to make sure that your server’s clock is accurate and synchronizes with the time on Stripe’s servers.

Stripe generates the timestamp and signature each time we send an event to your endpoint. If Stripe retries an event (for example, your endpoint previously replied with a non-2xx status code), then we generate a new signature and timestamp for the new delivery attempt.

Quickly return a 2xx response

Your endpoint must quickly return a successful status code (2xx) prior to any complex logic that could cause a timeout. For example, you must return a 200 response before updating a customer’s invoice as paid in your accounting system.

Verifying signatures manually

Although we recommend that you use our official libraries to verify webhook event signatures, you can create a custom solution by following this section.

The Stripe-Signature header included in each signed event contains a timestamp and one or more signatures that you must verify. The timestamp is prefixed by t=, and each signature is prefixed by a scheme. Schemes start with v, followed by an integer. Currently, the only valid live signature scheme is v1. To aid with testing, Stripe sends an additional signature with a fake v0 scheme, for test mode events.

Stripe-Signature:
t=1492774577,
v1=5257a869e7ecebeda32affa62cdca3fa51cad7e77a0e56ff536d0ce8e108d8bd,
v0=6ffbb59b2300aae63f272406069a9788598b792a944a07aba816edb039989a39

Stripe generates signatures using a hash-based message authentication code (HMAC) with SHA-256. To prevent downgrade attacks, ignore all schemes that are not v1.

You can have multiple signatures with the same scheme-secret pair when you roll an endpoint’s secret, and keep the previous secret active for up to 24 hours. During this time, your endpoint has multiple active secrets and Stripe generates one signature for each secret.

To create a manual solution for verifying signatures, you must complete the following steps:

Step 1: Extract the timestamp and signatures from the header

Split the header using the , character as the separator to get a list of elements. Then split each element using the = character as the separator to get a prefix and value pair.

The value for the prefix t corresponds to the timestamp, and v1 corresponds to the signature (or signatures). You can discard all other elements.

Step 2: Prepare the signed_payload string

The signed_payload string is created by concatenating:

• The timestamp (as a string)
• The character .
• The actual JSON payload (that is, the request body)

Step 3: Determine the expected signature

Compute an HMAC with the SHA256 hash function. Use the endpoint’s signing secret as the key, and use the signed_payload string as the message.

Step 4: Compare the signatures

Compare the signature (or signatures) in the header to the expected signature. For an equality match, compute the difference between the current timestamp and the received timestamp, then decide if the difference is within your tolerance.

To protect against timing attacks, use a constant-time-string comparison to compare the expected signature to each of the received signatures.